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ABSTRACT 


This  thesis  develops  a  concept  for  integrating  decision  support  technologies  with 
global  computer  networks.  It  introduces  a  new  paradigm  for  the  distribution  and  use 
of  algorithms,  decision  support  applications,  models,  and  simulations.  Under  this 
paradigm,  all  mechanisms  to  allow  for  interactions  between  providers  of  tech¬ 
nologies  and  consumers  who  wish  to  use  them  are  facilitated  by  a  distributed  decision 
support  server.  Additionally,  this  thesis  analyzes  the  concept  of  distributing  decision 
technologies  as  a  service  vice  a  software  product.  It  develops  the  initial  framework 
architecture  and  proposes  an  infrastructure  for  a  distributed  decision  support  network. 

Decision  support  systems  have  traditionally  been  developed  as  stand  alone 
applications  which  conform  to  a  specific  users  hardware  and  software  requirements. 
This  leads  to  reduced  sharing  and  reuse  of  the  application  as  well  as  the  data,  models, 
and  algorithms  incorporated  within  the  application.  The  Internet,  WWW,  and 
enabling  technologies  allow  for  the  dissemination  of  multimedia  information  to 
support  diverse  groups  of  remote  users.  This  thesis  demonstrates  that  decision 
support  technologies  can  also  be  made  available  to  users  of  a  heterogeneous  network 
in  a  similar  manner. 
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I.  INTRODUCTION 


“Defense  modeling  and  simulation  will  provide  readily  available,  operationally  valid 
environments...to  train  jointly,...formulate  operational  plans,  and  assess  warfighting 
situations.”  DoD  EXCIMS, 

March  1992 


“We  have  the  following  strategic  requirements  for  Modeling  and  Simulation...  direct 
interface  capability  with  operational  C4I  systems  (comms,  ADP,  ADA)” 

Brig  Gen  Michael  C.  Short,  USAF 
Director  of  Training,  U.S.  Atlantic  Command 
November  1993 


“The  organization  that  will  excel ...  will  be  those  that  manage  information  as  a  major 
resource”  (Synott,  1981) 

A.  BACKGROUND 

The  purpose  of  this  thesis  is  to  develop  a  framework  architecture  for  the  distribution 
of  decision  support  technologies'  in  a  client  server  environment  over  a  network  using 
Transmission  Control  Protocol/Intemet  Protocol  (TCP/IP).  The  open  architecture  design  of 
TCP/IP  has  enabled  the  dissemination  of  information  over  a  global  network  through  the  use 
of  Network  Information  Discovery  and  Retrieval  (NIDR)  tools  such  as  SMTP,  FTP,  WAIS, 
and  TCP/IP  applications  such  as  Telnet  and  Network  news.  (Sprague,  et  al.,  1993)  These 
tools  provide  for  a  friendly  user  interface  for  the  transfer  of  electronic  information.  The 
World  Wide  Web  (WWW)  has  allowed  the  functionalities  of  these  different  applications  to 
be  combined  imder  a  single  integrated  browser  application.  (Berners-Lee,  et  al.,  1994)  By 
means  of  a  simple  scripting  language  the  functionalities  of  these  applications  are  now  being 
used  in  conjimction  with  other  software  applications.  The  HyperText  Transfer  Protocol 


'Throughout  this  thesis,  decision  support  technologies  and  decision  technologies 
are  used  to  refer  to  a  variety  of  software  used  to  support  decision  making  and  modeling. 
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(HTTP)  and  HyperText  Mark-up  Language  (HTML)  has  created  an  opportunity  to  exploit 
the  functionalities  of  TCP/IP  applications.  (Berners-Lee,  1993) 

The  use  of  computer  support  to  aid  in  decision  making  is  required  in  many  situations 
due  to  the  volume  of  data  and/or  the  time  sensitive  nature  of  the  decision.  Development  of 
an  application  specific  DSS  is  a  lengthy  and  costly  process.  The  models  and  algorithms 
must  be  verified  and  validated  with  valid  data  sets.  Applications  are  continuously  updated 
due  to  changes  in  the  environment,  changes  in  data  requirements,  and  development  of  better 
algorithms.  The  life  of  a  decision  technology  is  usually  short,  as  it  is  may  only  support  one 
specific  decision.  This  technology  is  thus  archived  and  the  models  and  algorithms  used 
within  die  technology  are  lost  and  imavailable  to  users  that  may  need  to  make  the  same  or 
similar  decision.  Many  organizations  feel  that  it  is  not  cost  effective  to  buy  or  build  DSS’s 
for  a  specific  decision  process.  (Sprague,  1980)  This  suggests  that  some  applications  may 
be  better  served  as  a  service  rather  than  a  product.  The  customer  could  use  the  application 
and  not  be  concerned  with  the  management  issues  associated  with  ovraing  the  software 
product.  This  service  could  be  provided  by  constructing  a  Distributed  Decision  Support 
Network  (DDSN)  which  would  allow  a  consumer  to  connect  to  and  execute  an  application 
through  simple  hypertext  links  or  a  Graphical  User  Interface  (GUI). 

Industry  and  the  Department  of  Defense  (DoD)  are  moving  rapidly  to  distributed 
systems,  common  operating  environments,  client  server  configurations,  and  object  oriented 
databases.  (Krai,  January  1995)  These  technology  upgrades  will  preclude  the  use  of 
legacy/standalone  decision  technologies  by  all  users  of  the  distributed  environment.  To  take 
full  advantage  of  new  technology,  existing  tools  will  need  to  be  re-engineered  to  operate 
within  the  new  operating  environment.  This  is  likely  to  be  a  timely  and  costly  evolution. 

An  alternate  solution  would  be  to  distribute  the  existing  legacy  DSS  applications/tools  to 
users  of  the  distributed  network. 

B.  OBJECTIVES 

The  goal  of  this  thesis  is  to  outline  an  architecture  and  propose  an  infrastructure  to 
facilitate  the  distribution  of  decision  technologies  over  a  global  network.  This  is  done  by 
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establishing  the  idea  and  concepts  of  operation  of  the  DDSN;  identifying  the  functionality 
required  between  all  entities  of  the  system;  and  modeling  the  activities  associated  with  the 
distribution  of  decision  technologies.  Through  a  rapid  prototyping  methodology,  the 
responsibilities  and  transactions  of  all  entities  of  the  DDSN,  will  be  substantiated.  Once  the 
architecture  is  developed,  it  is  the  authors  intent  to  identify  current  capabilities  and  initiatives 
that  relate  to  the  architecture  proposed,  and  to  suggest  areas  where  this  technology  can  best 
be  exploited  by  organizations  in  commercial  industry  and  the  DOD. 

C.  ORGANIZATION  OF  THESIS 

This  thesis  is  organized  into  six  chapters  and  two  appendices. 

The  first  chapter  contains  the  introduction  and  overview  of  this  thesis.  The  second 
chapter  conveys  the  motivation  and  arguments  for  building  a  framework  to  distribute 
decision  support  technologies.  Chapter  III  examines  the  environment  of  the  DDSN  and 
identifies  the  roles  and  responsibilities  of  entities  of  the  DDSN  environment.  Chapter  IV 
examines  the  functions  of  the  DDSS,  identifies  an  arehitectural  framework  for  the  DDSN, 
and  proposes  an  initial  infrastructure  for  the  DDSN.  Both  appendices  of  the  thesis  support 
Chapter  IV.  Appendix  A  discusses  enabling  technologies.  Appendix  B  illustrates  the  IDEF 
0  model  developed  to  investigate  the  activities  and  the  interaction  of  activities  within  the 
DDSS.  Chapter  V  discusses  the  objectives  of  models  and  simulations  within  DoD  and  how 
the  DoD  can  exploit  the  DDSN  technology.  Chapter  VI  is  the  thesis  conclusion  and  suggest 
areas  that  require  further  research. 
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II.  WHY  BUILD  A  DISTRIBUTED  DECISION  SUPPORT  NETWORK? 


A.  INTRODUCTION 

Research  in  the  decision  sciences  has  resulted  in  the  development  of  modeling  and 
decision  support  applications  that  are  useful  in  solving  a  variety  of  problems  faced  by 
individiials  and  organizations.  (Davis,  1988)  Decision  Support  Systems  (DSS)  aim  to 
provide  support  for  semi-structured  and  unstructured  decisions  in  all  stages  of  the  decision 
process.  DSS  requires  a  unique  interface  between  the  user  and  internal  databases,  external 
databases,  and  analytical  models.  The  dawn  of  the  information  age  has  brought  greater 
demand  for  computer  assistance  in  decision  making  due  to  the  abundance  of  information, 
the  ease  with  which  it  is  obtained,  and  the  time  sensitive  nature  in  which  decisions  are  made. 

Enabling  technologies  (client  server  applications,  object  oriented  design,  work  flow 
management  tools)  have  reduced  imcertainty  in  decision  making  by  making  data  more 
readily  available  to  decision  makers  at  all  levels  of  the  organization.  However,  many 
decision  makers  are  overwhelmed  by  the  amoimt  of  new  data  and  delay  making  a  decision 
until  the  data  can  be  understood.  Ftirthermore,  these  technologies  have  also  introduced 
complex  interdependicies  between  the  organizational  structure  and  the  information  system. 
(Walton,  1989)  These  interdependicies  have  changed  the  organizational  structure,  which 
has  redefined  who  makes  the  decisions  within  the  organization.  To  adequately  support  the 
decision  making  process  of  today’s  organization,  a  variety  of  decision  support  applications 
need  to  be  available  to  all  users  of  the  organization  on  demand.  In  addition  to  a  suite  of 
tools  for  known  re-occurring  decisions,  organizations  will  require  access  to  a  repository  of 
decision  support  technologies  for  unexpected  and  dynamic  events  introduced  by  the 
environment.  This  new  paradigm  suggests  that  the  decision  sciences  should  exploit  these 
enabling  technologies  in  the  development,  interface,  and  distribution  of  decision  tech¬ 
nologies. 

The  underlying  idea  of  a  DDSN  is  to  create  an  electronic  market  for  decision  support 
applications.  This  market  would  allow  decision  support  and  modeling  systems  to  be 
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delivered  as  a  service  rather  than  as  a  product.  (Bhargava,  et  al.,  1995)  By  distributing 
these  technologies  as  services,  it  is  believed  five  categories  of  resources  that  are  traditionally 
used  in  modeling  and  decision  making  (data,  models,  simulations,  solvers,  and  decision 
support  packages)  can  be  made  available  to  all  users  of  the  network.  This  market  will  allow 
a  multitude  of  users  access  to  a  diverse  library  of  tools.  Potential  users  of  this  service  include 
research  activities,  academia  (professors  and  students),  military  organizations,  industry,  as 
well  as  casual  users  who  occasionally  need  problem  solving  or  assistance  in  making  a 
decision. 

This  chapter  examines  the  ideas  behind  developing  a  DDSN  and  the  benefits  of 
distributing  decision  technologies  as  a  service  over  a  global  network,  such  as  the  Internet. 

B.  ELECTRONIC  COMMERCE 

The  emergence  of  the  National  Information  Infrastructure  (Nil)  and  the  development 
of  Internet  applications  such  as  the  WWW  have  brought  much  attention  to  electronic 
commerce.  The  ultimate  goal  of  the  Nil  in  Electronic  Commerce  is  the  creation  of  a 
national  electronic  marketplace  which  is  secure,  open,  affordable,  easy  to  access,  and  easy 
to  use.  (Gebase  et  al.,  1993) 

1.  Commercial  Business  and  the  WWW 

Today,  while  surfing  the  WWW,  you  can  order  a  pizza  from  Pizza  Hut,  visit  the 
archives  of  the  Library  of  Congress,  read  the  San  Jose  Mercury  News,  view  video  clips, 
listen  to  music,  and  go  shopping  in  the  Internet  Mall.  There  is  no  other  medium  that  is 
accessible  to  such  variety  of  services  and  on-line  fimctionality.  The  WWW  and  the  Internet 
have  demonstrated  a  great  commercial  opportunity.  Commercial  business  on  the  Internet 
is  expanding  expeditiously,  even  with  moderate  security  in  place.  The  commercial  domain 
is  the  fastest  growing  Internet  group,  with  more  than  1,500  new  companies  connecting  to  the 
Internet  each  month.  The  commercial  sector  now  makes  up  more  than  one-half  of  all  domain 
names  according  to  Internet  Society  figures.  (Ellsworth,  1995)  Figure  1  illustrates  the  large 
growth  of  the  Internet  and  the  WWW. 
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Figure  1.  WWW  Growth  on  the  Internet 


2.  Electronic  Data  Interchange  (EDI) 

EDI  is  presently  being  used  by  many  individuals  and  organizations  to  automate 
simple  business  decisions  and  financial  transactions.  These  transactions  have  evolved  to 
reduce  paperwork  and  to  increase  the  speed  and  availability  of  decision  making  information 
for  business  and  government  transactions.  An  advanced  Nil  for  Electronic  Commerce  will 
be  able  to  support  activities  such  as  electronic  fimds  transfer,  government  regulatory  data 
interchanges,  enterprise  integration,  and  computer-supported  collaborative  work.  (DoD, 
1993)  (Gebase,  et  al.,  1995)  The  Nil  provides  the  enabling  technologies  for  an  electronic 
market  of  decision  technologies.  It  would  allow  for  decision  technologies  to  be  made 
available  to  users  via  a  virtual  repository.  This  repository  of  decision  technologies  will  allow 
users  to  access  and  use  decision  technologies  in  conjunction  with  organizational  data  as  well 
as  external  data  sources.  Potential  users  of  this  service  include  research  activities,  academia 
(professors  and  students),  military  organizations,  industry,  as  well  as  casual  users  who 
occasionally  need  problem  solving  or  assistance  in  making  a  decision. 
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C.  ARGUMENTS  FOR  DISTRIBUTING  DECISION  SUPPORT  TECH¬ 
NOLOGIES 

The  Internet  and  associated  NIDR  tools  have  streamlined  the  transfer  of  electronic 
data,  which  includes  executable  software  applications.  (Abernathy,  1995)  (Krol,  1994) 
Presently,  a  variety  of  public  domain  executable  applications  may  be  downloaded  from  sites 
aroimd  the  world.  However,  this  approach  places  additional  requirements  on  both  the 
developer  and  the  user  of  the  application.  The  developer  must  port  the  application  for 
different  platforms  and  the  user  must  have  the  knowledge  to  install,  configure,  and  maintain 
the  application  on  his  computer.  The  same  holds  true  for  decision  technologies;  a  model  or 
algorithm  can  not  be  processed  in  real  time  by  a  solver  which  does  not  exist  on  the  clients 
machine. 

The  remote  execution  of  these  applications  can  be  done  by  a  procedure  call  through 
a  Common  Gateway  Interface  (CGI)  which  is  used  by  the  HTTP  servers  of  the  WWW.  CGI 
allows  for  a  simple  user  interface,  making  the  execution  of  NIDR  applications  transparent 
to  the  user.  The  infrastmcture  of  the  DDSN  and  the  providers  decision  technology  can  thus 
absorb  a  majority  of  task  usually  associated  with  the  user.  There  are  four  main  arguments 
for  building  such  an  infrastmcture:  market  potential,  version  management,  the  me  vs.  own, 
and  the  interoperability  or  shareability  argument. 

1.  The  Market  Potential  Argument 

By  definition,  there  are  limited-niche-markets  for  specific  decision  support 
applications/tools;  the  more  specific  a  system  is,  the  smaller  its  potential  base  of  users.  The 
lack  of  a  large  enough  market  for  various  decision  technologies  may  often  inhibit  their 
development  and  availability.  Many  types  of  models  are  developed  for  ad  hoc  decisions  for 
a  specific  organization,  used  once,  put  on  the  shelf,  not  maintained,  and  never  used  again. 
By  providing  technologies  through  a  repository,  such  models  would  be  available  to  a  diverse 
set  of  users;  expanding  the  market  for  such  a  model.  The  cost  of  reaching  this  market  would 
be  a  fraction  of  the  costs  associated  with  conventional  distribution  channels.  Users  would 
be  able  to  learn  about  and  access  a  large  number  of  decision  technologies  without  obtaining 
the  maintenance  cost  associated  with  tire  purchase  and/or  development  of  these  applications. 
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They  could  browse  freely,  a  yellow  pages  of  technologies,  identifying  applications  that 
would  be  beneficial  in  their  decision  making  process. 

2.  The  Version  Management  Argument 

This  argument  is  analogous  with  a  client  server  application.  For  example,  an 
organization  buys  a  client  server  word  processing  application.  The  application  is  installed 
and  maintained  by  the  system  administrator  on  one  computer  (application  server).  Users  of 
the  network  use  the  application  as  if  it  were  installed  on  their  terminal.  When  a  new  version 
is  installed  or  a  bug  is  fixed  in  an  application,  the  administrator  updates  the  software  at  the 
server,  the  change  is  made  transparent  to  all  users.  The  cost  and  time  required  to  implement 
the  change  decreases  proportionally  by  the  number  of  users  of  the  application.  The  version 
management  argument  for  a  DDSN  is  that  an  electronic  network  would  eliminate,  or 
minimize,  many  of  the  costs  and  problems  associated  with  updating  software  technologies 
when  many  copies  and  many  versions  of  the  same  technology  are  physically  distributed. 
Providers  would  not  have  to  create  and  distribute  multiple  copies  of  a  product  since  the 
application  would  be  running  at  the  providers  computer.  Updates  and  new  releases  would 
be  made  available  simply  by  setting  them  up  for  execution  and  listing  them  in  the  DDSN 
database.  All  transactions  would  be  done  electronically,  eliminating  the  need  to  package, 
bill,  and  mail  via  traditional  methods. 

3.  The  Use  vs.  Own  Argument 

Many  potential  consumers  of  decision  technologies  are  vmwilling  to  invest  the  time, 
money,  and  effort  required  to  learn  about,  obtain,  own,  and  use  them,  particularly  when  the 
decision  problem  is  non-recurring.  Further,  buyers  of  decision  technologies  have  to  deal 
with  the  maintenance  cost  and  updates  required  due  to  changes  in  model  situation  or  change 
in  data  structures.  By  owning  a  software  product  the  user  must  provide  for  the  management 
of  the  product  and  must  determine  if  the  application  is  providing  the  added  value  that  it  was 
originally  purchased  for.  A  DDSN  would  allow  a  consumer  to  use  a  decision  technology, 
when  needed,  and  be  free  of  the  problems  associated  with  owning  and  managing  the 
software.  This  would  promote  a  "pay"  for  use,  vice  purchasing  and  maintaining  a  copy  of, 
a  decision  technology.  The  costs  and  time  associated  with  learning  about  a  decision 
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technology  and  using  it  as  a  service,  would  be  modest  compared  with  the  costs  associated 
with  doing  so  with  a  conventional  product. 

4.  The  Interoperability  and  Shareability  Argument 

Even  within  organizations  that  have  the  resources  to  develop  decision  technologies, 
a  repository  of  functional  technologies  offers  an  opportunity  to  share  these  technologies. 
This  is  particularly  true  when  the  organization  is  geographically  dispersed  and/or  utilize  a 
variety  of  hardware  and  software  platforms.  The  DoD  CIM  initiative  illustrates  the  need  to 
combine  information  resources  to  reduce  development  and  maintenance  cost  of  information 
systems  in  future  years.  DoD  and  many  commercial  organizations  of  today  are  restructuring 
their  organizational  structure  and  redefining  their  business  processes.  (Appleton,  1993)  This 
is  due  to  enhanced  technology  and  the  need  to  minimize  cost.  Organizations  of  today  are 
geographically  dispersed,  but  share  the  same  data  resources.  The  DDSN  would  maintain  a 
centralized  library  of  decision  technologies,  allowing  for  decision  technologies  to  be  globally 
shared  to  dispersed  organizations.  This  would  increase  awareness  and  knowledge  of  these 
technologies  within  an  organization,  allowing  decision  makers  at  all  levels  access  to  tools 
registered  with  the  DDSN,  regardless  of  the  users  hardware. 

D.  CONCLUSIONS 

The  ability  to  make  expedient  and  correct  decisions  in  today’s  computing  environ¬ 
ment  requires  the  decision  maker  to  have  access  to  current  data  and  the  correct  decision  aids 
to  process  and  visulize  the  data.  Traditional  research  in  the  development  of  DSS’s  is  being 
challenged  by  new  technologies,  reorganization  of  organizational  structures,  and  redefining 
who  really  makes  the  decisions  within  the  organization.  Researchers  and  developers  of  the 
decision  sciences  will  need  to  exploit  these  enabling  technologies  and  re-engineer  the  way 
decision  support  applications  are  used,  developed,  and  distributed  to  accommodate  the 
modem  organizational  stmcture.  A  DDSN  is  one  way  in  which  existing  technologies  can 
be  utilized  by  consumers  of  enterprise  and  global  networks.  This  architecture  will  provide 
a  high  degree  of  interoperability  and  place  minimal  constraints  on  users'  hardware  and 
software  environments,  while  allowing  them  to  use  technologies  residing  on  many  different 
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kinds  of  computer  platforms.  By  creating  an  electronic  market  for  decision  support 
applications/tools  the  developers  and  researchers  in  the  decision  sciences  can  bring  data, 
models,  simulations,  solvers,  and  decision  support  packages  to  the  largest  growing  medium 
of  information.  This  market  will  facilitate  the  advertisement  as  well  as  the  use  of  these 
technologies;  expanding  the  market  and  availability  of  these  technologies. 
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III.  CONCEPT  OF  OPERATION 


A.  INTRODUCTION 

Electronic  services  in  marketing,  banking,  and  travel  are  becoming  popular  on  the 
Internet  via  the  WWW.  These  services  require  on-line  interaction  between  the  customer  and 
the  provider  of  the  service.  The  provider  of  these  services  must  also  provide  back-end 
processing  to  render  the  service  to  the  customer.  A  few  decision  support  technologies  are 
also  available  on  the  WWW.  An  application  called  Waste  Management  Technology 
Analysis  and  Decision  Support  (WMTADS)  is  operated  by  the  Department  of  Energy 
(DOE).  A  user  can  search  DOE  technologies  for  treating  waste  as  well  as  search  for  specific 
industry  solutions  to  the  technological  challenge  of  treating  wastes.^  (DOE,  1994)  The 
back-end  processing  of  this  type  of  technology  provides  for  all  the  interaction  of  all 
databases  and  analytical  models  of  the  providers  DSS  with  the  users  provided  input  data. 
The  Common  Gateway  Interface  (CGI)  allows  for  the  transfer  of  input  data  to  the  provider, 
execution  of  the  application,  and  the  return  of  output  data  to  the  user.  (NSC  A,  1 995)  This 
allows  for  the  distribution  of  the  technology  over  a  heterogeneous  network  using  a  common 
interface,  but  does  not  allow  for  interoperability  between  technologies. 

One  way  to  achieve  interoperability  between  decision  technologies  across  diverse 
hosts  and  operating  systems  is  through  a  Common  Operating  Environment  (COE).  A  COE 
consist  of  a  special  software  layer,  such  as  CRONUS,  or  a  level  of  architecture,  and  object 
standardization  as  in  the  CORE  A  standard.  (Krai,  1995)  Interoperability  between  registered 
technologies  of  the  DDSN  would  be  achieved  by  constructing  an  architecture  in  which  agents 
would  mediate  the  transactions  between  the  users  (consumers  and  providers)  and  between 
different  technologies.  (Bhargava,  et  al.,  July  1995)  To  better  understand  the  requirements 
of  this  architecture,  the  entities,  transactions,  and  requirements  of  all  entities  must  first  be 
identified.  This  chapter  develops  the  requirements  and  responsibilities  of  the  entities  of  the 
DDSN  environment  and  defines  the  transactions  between  entities  of  the  DDSN. 


^WMTADS  is  available  at  URL:  http://mwir.lanl.gov/. 
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B.  THE  DDSN  ENVIRONMENT 


The  DDSN  environment  consist  of  the  network,  providers  of  decision  technologies, 
consumers  of  decision  technologies,  and  the  Distributed  Decision  Support  Server  (DDSS) 
as  illustrated  in  Figure  2. 


1.  The  Network 

Allows  for  the  physical  transfer  of  data  and  the  seamless  interaction  between  different 
types  of  platforms.  All  entities  of  the  environment  are  assumed  to  have  access  to  the 
network.  It  is  believed  that  different  types  of  networks  could  facilitate  the  distribution  of 
decision  technologies,  however,  in  this  thesis  the  network  discussed  refers  to  the  Internet. 

2.  Providers 

Organizations,  developers  and/or  individuals  who  desire  their  decision  technology 
to  be  executable  over  the  network,  are  considered  providers.  The  provider  is  ultimately 
responsible  for  the  functionality  and  dependability  of  the  hardware  and  software  for  which 
the  application  runs.  The  provider  must  be  able  to  define  the  structure  for  inputs  and  outputs 
of  data  required  by  the  application.  The  provider  is  also  responsible  for  the  security  of  all 
input  data  from  the  consumer  and  the  results  produced  firom  the  application.  At  this  time, 
two  categories  of  providers  exist,  “Independent”  applications  and  “Exclusive”  applications. 
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a.  ^Independent”  Applications 

Providers  that  have  provided  a  CGI  for  their  applications  which  allow  for  the 
transfer  of  data  and  the  execution  of  their  application  need  only  to  register  as  a  provider  of 
the  decision  technology  and  register  the  application  with  the  DDSS.  The  application  can 
execute  independently  of  the  DDSS.  The  Uniform  Resource  Locator  (URL)  is  used  to 
interface  the  technology  with  the  consumers  of  the  DDSN. 

b.  “Exclusive”  Applications 

These  providers  must  also  register  as  a  provider  of  the  decision  technology 
and  register  the  decision  technology  itself  From  the  metadata  obtained  during  registration, 
a  series  of  HTML  documents  and  CGI  scripts  will  be  developed  by  the  DDSS  to  provide  the 
needed  interface  between  an  HTTP  server  and  the  providers  application  (Bhargava  et  al, 
Germany  June  95).  Such  applications  executes  exclusively  in  the  DDSS  environment. 
These  interfaces  will  be  technology  dependent  and  will  be  constrained  by  the  server  support 
of  the  provider. 

The  provider  is  also  responsible  for  maintaining  a  WWW  browser  application 
that  supports  die  use  of  HTML  forms;  this  is  required  for  on-line  registration  of  the  provider 
as  well  as  the  technology.  Depending  on  the  type  of  application,  the  provider  must  also 
provide  various  servers  (SMTP,  FTP,  Gopher,  etc.)  to  allow  for  the  transfer  of  input  data  as 
well  as  the  return  of  ouqiut  data  to  the  consumer. 

3.  Consumers 

A  consumer  of  the  DDSN  is  any  person  or  organization  who  is  in  the  market  for 
computational  decision  support  services  and  registers  with  the  DDSS.  The  consumer  is  the 
end  user  of  a  decision  technology  which  has  been  made  available  by  a  provider.  A  consumer 
is  responsible  for  maintaining  a  WWW  browser  application  that  supports  the  use  of  HTML 
forms  and  NIDR  tools  to  support  the  transfer  of  data  as  required.  Consumers  are  responsible 
for  the  decisions  made  from  the  use  of  applications  provided  via  the  DDSN. 


15 


4.  Distributed  Decision  Support  Server  (DDSS) 

The  DDSS  provides  the  mechanisms  which  allow  users  to  register,  search  for, 
connect  to,  and  execute  a  decision  technology.  The  DDSS  is  comprised  of  hardware,  soft¬ 
ware,  and  the  personnel  assets  which  allows  for  the  functionality  of  the  network.  It’s  purpose 
is  to  provide  mechanisms  for: 

•  On-line  registration. 

•  Validation  and  verification  of  users  and  technologies. 

•  Help  desk  service. 

•  Creation  of  a  common  interface  for  exclusive  technologies. 

•  Yellow  pages  of  executable  decision  technologies. 

•  Translation  of  data  structures  to  achieve  interoperability. 

•  Support  functions. 

C.  DDSN  TRANSACTIONS 

Transactions  are  initiated  by  the  users  of  the  DDSN  using  forms  capable  WWW 
browser  (Netscape  or  Mosaic)  and  are  mediated  by  agents  of  the  DDSS.  There  are  five 
categories  of  transactions  within  the  DDSN  environment:  registration,  log-in,  connectivity 
to  a  decision  technology,  execution  of  a  technology,  and  standard  support  functions  (all  other 
transactions  required  to  support  the  first  four  categories  of  transactions). 

1.  Registration 

All  users  of  the  network  are  required  to  register  with  the  DDSS.  This  is  done  on-line 
via  HTML  forms  or  offline  by  E-mail.  Registration  is  required  to  establish  access  via  login 
and  password  to  the  services  of  the  DDSS.  Registration  information  is  also  used  in  the 
management  functions  required  of  the  DDSS  (billing,  user  reports,  etc.).  Providers  must  also 
register  their  decision  technologies.  The  metadata  information  obtained  during  registration 
is  used  by  the  DDSS  to  verify,  validate,  accredidate,  and  construct  a  common  interface  as 
required.  A  validation  message  acknowledging  the  successful  registration  of  a  user  or  the 
state  of  a  technology  registration  is  sent  to  the  provider  by  the  DDSS  via  E-mail. 
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2.  Logging  In 

Once  a  user  is  registered  he  simply  logs  into  the  system  using  the  login  and  password 
established  at  registration.  Once  logged  in  the  user  can  activate  different  agents  within  the 
DDSS  to  obtain  the  functionality  (search,  browse,  edit  registration  information,  use  a 
technology)  desired. 

3.  Connectivity  to  an  Application 

Once  a  technology  is  selected  for  use,  the  user  initiates  a  request  via  a  hypertext  link 
or  GUI  to  the  DDSS  to  use  said  technology.  Due  to  the  stateless  state  of  the  HTTP  the  user 
is  cormected  directly  to  the  providers  or  warehouse  server  at  this  time.  The  user  can  read  and 
learn  more  about  the  application  and  will  then  be  asked  to  submit  data  and  invoke  execution 
of  the  application. 

4.  Execution 

a.  Input  Data  Transfer 

Since  the  DDSS  mediates  all  transactions,  the  data  is  sent  via  the  DDSS, 
translation  occurs,  and  the  data  is  forwarded  to  the  providers  site.  If  the  application  is  an 
independent  technology,  a  translation  process  is  not  required,  therefore,  the  input  data  is  sent 
directly  to  the  provider. 

b.  Invoking  Execution 

Once  the  data  is  made  available  to  the  provider,  the  application  is  invoked  by 
either  the  consumer  or  the  DDSS.  Again  this  is  dependent  on  the  t5q)e  of  application.  Use 
of  an  exclusive  or  invoking  multiple  applications  would  require  the  DDSS  to  monitor  the 
state  of  each  process  and  invoke  execution  once  the  processed  data  is  received  by  the  next 
application.  An  independent  technology  such  as  a  WMTADS  is  invoked  directly  by  the 
consumer  as  there  is  no  need  for  translation  of  the  output  data  for  input  to  another 
application. 

c.  Receipt  of  Output  Data 

Once  the  application  completes  processing,  the  output  data  is  sent  back  to  the 
user  and  the  DDSS.  If  it  is  a  single  transaction,  the  transaction  is  complete  upon  receipt  of 
the  output  data.  The  consumer  can  then  use  the  technology  again  or  use  another  application. 
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For  multiple  application  processes  the  output  data  is  converted  by  agents  at  the  DDSS  and 
made  available  as  inputs  to  the  next  application.  Once  the  data  is  available  at  the  next  site 
the  DDSS  invokes  execution  of  the  application.  This  continues  until  the  process  is  complete. 
The  user  will  receive  ou^ut  data  from  each  application  used. 

5.  Standard  Support 

These  transactions  may  be  directly  or  indirectly  initiated  by  the  user.  This  support 
can  be  broken  into  two  categories;  help  desk  and  management. 

a.  Help  desk 

Most  of  die  functions  of  the  DDSN  are  automated,  however,  a  need  exists  for 
a  mechanism  to  allow  interaction  between  users  and  the  DDSS  staff.  Initially,  a  help  desk 
between  users  and  the  DDSS  staff  is  envisioned  using  standard  collaboration  tools.  These 
tools  include  E-mail,  list  serves,  news  groups,  and  PC  video  conference.  A  consumer  can 
get  help  on  the  use  of  a  decision  technology  and  a  provider  can  get  assistance  in  registering 
a  new  technology. 

b.  Management 

These  transactions  are  those  that  are  indirectly  initiated  by  the  users  by  simply 
using  the  network.  This  transactions  consist  of:  user  verification  messages,  technology 
usage  reports,  general  management  reports  (consumers,  providers,  technologies  available), 
and  billing  summaries. 

D.  CONCLUSIONS 

This  chapter  is  informative  in  nature  and  gives  the  reader  a  comprehension  of  the 
functions  of  the  overall  system.  By  identifying  the  roles  and  responsibilities  of  all  entities 
and  the  transactions  required  between  those  entities,  it  is  evident  that  the  architecture  and 
infrastructure  of  the  DDSS  is  a  determinant  factor.  The  DDSS  architecture  will  replace  the 
software  layer  and  the  requirement  for  standardized  data  objects  as  used  in  the  COE.  It  is 
believed  that  this  will  provide  consumers  with  greater  availability  and  flexibility  in  using 
teehnologies  and  external  data  sets  in  problem  solving  and  decision  support.  Defining  the 
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DDSN  architecture  is  crucial  in  developing  the  mechanisms  of  the  DDSS  and  is  the  focus 
of  further  research. 
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IV.  DDSN  ARCHITECTURAL  OVERVIEW 


A.  INTRODUCTION 

The  tenii  architecture  and  infrastructure  are  used  diversely  and  interchangeably  by 
professionals  of  information  technology.  Webster  dictionary  defines  these  terms  as: 

Architecture:  The  design  or  structure  of  something. 

Infrastructure:  The  basic  framework  of  a  system  or  organization;  fundamental 

facilities,  as  transportation  and  communication  systems. 

For  the  purpose  of  this  thesis  the  following  definitions  are  provided: 

Architecture  -  The  structure  of  components  in  a  system,  their  interrelationships, 
and  principles  and  guidelines  governing  their  design  and 
development  over  time. 

Infrastmcture  -  Resources  (personnel,  hardware,  software,  communications)  used 
to  achieve  desired  functionalities  of  a  system. 

This  chapter  presents  an  overview  of  the  DDSN  architecture  and  discusses  DDSN 
infrastructure  requirements  by  examining  the  requirements  of  each  entity. 

B.  DEFINING  THE  DDSN  ARCHITECTURE 

The  main  objective  of  the  DDSN  architecture  is  to  provide  a  truly  heterogeneous 
system  to  users  with  minimal  standards  and  conventions  mandated.  The  architecture  v^ll 
allow  users  freedom  of  choice  in  use  of  a  browser  to  access  the  DDSN  and  will  not  require 
compliance  of  standards  and  conventions  in  die  development  of  decision  technologies.  The 
architecture  will  additionally  allow  for  interoperability  between  applications  by  using 
translation  mechanisms  vice  traditional  COE  technology.  The  initial  DDSN  architecture  is 
based  on  common  interface  standards  presently  used  by  the  WWW,  additional  components 
will  be  added  at  different  stages  of  development  to  introduce  new  functionality.  The  initial 
architecture  framework  of  the  DDSN  is  defined  by:  defining  the  development  stages  of  the 


21 


DDSN,  reviewing  objectives  of  the  system,  addressing  teehnical  considerations  in  achieving 
the  system  objectives,  illustrating  a  reference  architecture,  and  identifying  required  standards. 

1.  DDSN  Development  Stages 

The  development  of  the  DDSN  will  be  done  in  progressive  stages  due  to  different 
levels  of  complexity  in  functionality,  evolving  technologies,  and  some  unresolved  issues. 
Each  development  stage  will  allow  more  functionality  to  the  users  of  the  DDSN.  Six  levels 
of  development  are  identified  below:  (Bhargava,  et  al.,  February  1995) 

a.  Level  0:  A  Repository  of  Available  Decision  Technologies 

This  is  nothing  more  than  a  searchable  electronic  library  of  technologies  in 
which  the  user  can  search  for  and  learn  about  a  decision  technology. 

b.  Level  lA:  A  Repository  of  Executable  Decision  Technologies 

This  level  introduces  invoking  execution  of  the  technology  by  the  consumer. 

After  searching  for  an  appropriate  technology  to  solve  a  specific  problem,  the  consumer  can 
select  one  for  use.  The  consumer  can  transfer  data,  invoke  execution,  and  receive  an  output 
from  the  application,  all  of  this  by  using  a  WWW  browser. 

c.  Level  IB:  Automating  Setup  of  Decision  Technologies 

Level  IB  automates  the  creation  of  the  provider’s  interface.  This  is  a  software 
module  which  will  automatically  generate  the  scripts  and  files  required  from  the  metadata, 
provided  during  registration. 

d.  Level  2A :  Using  Multiple  Applications  to  Solve  Problems 

This  level  will  allow  interoperability  between  technologies.  The  user  initiates 
sequencing  of  technologies  and  transfer  of  data,  but  the  DDSS  will  do  the  translation  of  data 
types. 

e.  Level  2B:  User  Defined  Multiple  Use  of  Technologies 

The  consumer  initiates  usage  of  a  sequence  of  technologies  to  be  used  and 
transfers  the  initial  data  to  the  DDSS.  The  DDSS  will  have  the  knowledge  about  the 
technologies  and  where  they  exist  to  translate  the  data  set  and  transfer  it  to  the  first 
technology.  Upon  completion,  the  ouqjut  of  the  first  technology  is  sent  back  to  the  DDSS, 
translation  occurs  and  the  data  is  sent  to  the  next  technology.  This  process  continues  until 
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the  end  of  the  sequence.  The  consumer  receives  an  output  from  each  technology  used  in  the 
process,  allowing  the  consumer  to  monitor  progress. 

f.  Level  3:  Use  of  Intelligent  Agents  to  Select  Technology  for  Use 

The  final  level  of  development  provides  intelligent  problem  solving  by  using 
intelligent  agents  to  choose  the  best  technology  alternative.  The  consumer  would  simply 
state  the  problem,  the  DDSS,  using  an  intelligent  search  agent  would  then  find  the  best 
technology  or  sequence  of  technologies  to  solve  the  given  problem.  The  consumer  would 
need  only  to  transfer  data,  initiate  execution,  and  receive  output  data. 

2.  Architecture  Objectives  of  the  DDSN 

Chapter  III  of  this  thesis  identified  the  transactions  required  within  the  DDSN.  From 
those  transactions  we  identify  the  following  architecture  objectives  are  identified. 

a.  Transparency 

Network  navigation,  transfer  of  data,  security  of  information,  input  formats, 
data  storage,  and  search  mechanism  will  be  internal  functionalities  of  the  DDSS.  This  will 
create  a  seamless,  transparent  interface  for  the  completion  of  these  functions.  The  interface 
needs  to  be  simplistic  to  fit  the  diverse  user  group  of  the  DDSN. 

b.  Interoperability 

The  decision  technologies  accredited  for  use  on  the  DDSN  will  allow  for 
heterogeneous  use.  Additionally,  the  DDSS  will  allow  interaction  between  applications  to 
support  sequencing  of  multiple  technologies  for  problems  that  require  multiple  applications. 

c.  Uniformity 

The  user  will  see  the  same  interface  no  matter  what  computer  platform  is 

used. 

d.  Flexibility/Extensibility 

New  technologies  can  be  added  to  the  network  without  any  effect  on  existing 
technologies.  From  the  users  perspective,  the  network  will  provide  a  variety  of  technologies, 
used  by  a  diverse  set  of  users  in  changing  environments. 
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e.  Distributed  Environment 

Users,  providers,  and  technologies  will  be  geographically  dispersed  and 
connected  by  an  electronic  virtual  heterogeneous  network.  This  will  allow  for  limited 
resource  requirements  to  obtain  decision  support  services  any  time,  any  place. 

3.  Technical  Considerations 

The  idea  behind  a  DDSN  is  based  on  new  and  evolving  technologies  and  the 
development  of  software  agents  as  translation  mechanisms  instead  of  a  COE.  Technical 
considerations  will  heavily  influence  the  DDSN  architecture  and  infrastructure.  The  DDSN 
architecture  must  allow  for  these  future  technologies  and  concepts  to  evolve. 

a.  Enabling  Technologies 

Appendix  A  identifies  the  enabling  technologies  that  the  author  feels  will  be 
essential  in  the  successful  development  of  a  DDSN. 

b.  Unique  DDSN  Software  Development 

The  software  agents  and  middleware  which  will  provide  for  automatic  regis¬ 
tration  and  interoperability  between  applications  are  a  critical  success  factor  in  the  proof  of 
concept  and  of  the  development  of  the  DDSN.  Requirements  are  presently  being  identified 
and  options  are  being  researched.  (Bhargava,  et  al.,  July  1995) 

4.  Architectural  Framework 

The  entities  of  the  DDSN  environment  were  previously  introduced  and  require  no 
further  explanation.  Figure  3  is  introduced  to  illustrate  a  reference  architecture  of  the  DDSN. 
This  architecture  can  be  described  as  a  conglomerate  of  provider  nodes  which  allow  their 
decision  technologies  to  be  accessed  and  used  by  a  variety  of  consumer  nodes  interlinked  and 
controlled  by  the  DDSS  node  via  a  global  network. 

5.  DDSN  Standards  and  Conventions 

A  major  goal  of  the  DDSN  idea  is  to  increase  availability  of  decision  technologies 
to  users  of  a  global  network.  COE’s  require  a  suite  of  common  tools  on  all  users’  machines. 
The  DDSN  idea  would  allow  consumers  to  use  browser  applications  of  their  choice; 
providers  can  build  applications  using  proprietary  software  and  run  the  application  on  the 
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computer  platform  of  their  choice.  We  believe  that  the  standards  and  conventions  can  be 
limited  to  the  defacto  standards  used  today  by  the  Internet  and  WWW.  To  obtain  minimal 
functionality,  all  users  must  initially  have:  connection  to  a  network,  a  TCP/IP  stack  installed, 
a  form’s  capable  browser,  and  complete  the  registration  process  as  a  consumer  or  provider. 

a.  Layered  Reference  Model 

An  architecture  from  the  perspective  of  a  reference  model  is  shown  in  Figure 
4.  This  model  was  developed  to  identify  standard  services  of  the  DDSN  and  to  provide  an 
elementary  view  of  the  DDSN  for  future  discussions.  The  reference  model  is  divided  into 
four  functional  layers:  the  physical  layer,  transport  layer,  DDSN  service  layer,  and  the 
application  layer. 
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Figure  4.  DDSN  Reference  Model 


(1)  Physical  Laver.  Consists  ofthe  communication  lines  required 
to  connect  to  the  network.  This  will  be  the  choice  of  the  consumer  and  provider  and  will 
vary  according  to  availability  of  services. 

(2)  Transport  Laver.  Communication  software  which  allows  for 
communication  functionality.  Commonly  called  TCP/IP  stack  or  DoD  protocol  stack. 

(3)  DDSN  Service  Laver.  This  layer  contains  users  defined  client 
software  which  allows  access  to  the  DDSS.  The  user  chooses  this  software,  but  must 
conform  to  specific  standards  ofthe  DDSS.  An  example  would  be  a  WWW  browser.  A  user 
can  use  the  browser  of  his  choice  if  it  is  HTML  2.0  acquiescent. 

(4)  Application  Laver.  This  layer  contains  all  exclusive  and 
independent  decision  technologies  previously  registered  and  available  for  use  on  the  DDSN. 
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b.  Functional  Standards 

DDSN  functionality  is  currently  based  on  the  technical  services  available  on 
the  WWW.  Table  1  identifies  the  recommended  or  de-facto  standards  for  each  of  the 
technical  services  to  achieve  the  following  functions  of  the  DDSS. 

(1)  User  Registration.  The  user  establishes  an  accoimt  with  the 
network  by  providing  pertinent  information  about  their  self  or  the  technology  they  are 
registering. 

(2)  Discovery  and  Search.  A  mechanism  to  search  for  and  learn 
about  a  decision  technology. 

(3)  Data  Transfer.  The  transparent  transfer  of  data  between 
consumer  and  provider,  provider  and  user,  and  technology  and  technology. 

(4)  Execution  of  Applications.  This  function  invokes  execution 

of  an  application. 

(5)  Support  Functions.  All  additional  functions  required  to 
support  users  of  the  network.  These  ftuictions  would  include  such  things  as:  On-line  help 
services,  reports,  validation  messages,  and  all  management  functions. 

C.  DDSN  INFRASTRUCTURE 

The  DDSN  infrastructure  is  comprised  really  of  three  separate  infrastructures 
(consumers,  providers,  DDSS)  which  a  fourth  infrastructure  (communication)  unites.  The 
absence  of  any  one  of  these  infrastructures  will  desolate  the  DDSN  concept.  In  developing 
the  DDSN  infrastructure,  discussing  connectivity,  hardware,  software,  and  personnel 
requirements  introduces  the  requirements  of  each  infrastructure  in  general  terms.  A  specific 
infrastructure  will  depend  on  the  stage  of  development,  established  performance  measures, 
amount  of  usage,  types  of  data  transfers,  and  known  interdependicies  between  specific 
resources.  More  emphasis  is  placed  on  the  DDSS  infrastructure  as  it  is  the  main  entity  of  the 
DDSN. 
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Table  1.  Functional  and  Technical  Standards  Cross  Referenced 


1.  DDSN  Communication  Network  Infrastructure 

A  network  infrastructure  capable  of  dealing  with  the  amount  and  type  of  data 
envisioned  to  seamlessly  integrate  all  simulation  and  modeling  technologies  does  not 
currently  exist.  The  Defense  Simulation  Internet  (DSI)  program  is  accelerating  commercial 
development  of  the  technologies  needed  by  the  simulation  community  for  distributed  work 
environments.  “The  ultimate  goal  is  deployment  of  a  gigabit  network  that  will  be  inter¬ 
operable  with  commercial,  optical  and  secure  wireless  networks.”  (ARPA,  1995)  Use  of  the 
DSI  or  a  comparable  network  is  required  to  use  the  DDSN  as  a  global  network. 

2.  Consumer  Infrastructure 

Three  areas  of  concern  for  the  consumer’s  infrastructure  exist:  access  to  the  network, 
computer  platform,  and  required  software. 

a.  Network  Access 

The  type  and  speed  of  a  network  access  are  dependent  on  each  consumer’s 
individual  requirement.  ISDN  and  ATM  technology  are  presently  increasing  the  bandwidth 
availability  to  the  end  user.  Internet  dial-in  connections  are  presently  available  at  14.4  or 
28.8  Kbps.  Consumers  with  ISDN  presently  connect  to  the  Internet  at  56  or  128  Kbps.  It 
is  projected  that  by  the  year  2004,  Internet  providers  will  provide  T1  carriers  to  the  home  for 
about  the  same  price  of  a  modem  connection  today.  (Robinson,  1995) 

b.  Hardware 

An  independent  variable  to  the  DDSN.  Hardware  used  is  dependent  on  the 
user  requirements. 

c.  Software 

The  only  required  software  is  TCP/IP  stack  software  and  a  WWW  browser 
client  which  combine  to  make  a  common  user  interface.  The  consumer  has  choice  in  which 
TCP/IP  stack  and  WWW  browsers  they  choose  to  use.  Additional  TCP/IP  software  applica¬ 
tions  such  as  an  E-mail  client  and  FTP  client  are  useful  to  the  user.  These  applications  are 
again  the  choice  of  the  end  user. 


29 


3.  Provider  Infrastructure 

The  provider  has  the  same  requirements  for  network  access,  but  has  additional 
requirements  in  hardware,  software,  and  personnel.  A  service  provider  must  provide  an 
infrastructure  which  provides  a  service  to  consumers  which  are  useful,  reliable,  and  secure. 

a.  Hardware  and  Software 

Providers  of  decision  technologies  will  have  freedom  of  choice  in  the 
hardware  and  software  required  to  provide  the  processing  of  the  decision  technology  and  the 
transfer  mechanism  to  support  the  transfer  of  input  and  output  data.  The  type  of  technology 
and  the  interface  requirements  of  the  application  will  drive  the  software  and  hardware 
requirements  for  the  provider. 

Hardware  and  software  requirements  will  be  much  less  for  independent 
providers  since  the  provider’s  HTTP  server  can  accomplish  the  transfer  of  data.  The 
provider  must  provide  the  hardware  and  software  to  run  an  HTTP  server  and  the  decision 
technology  application.  CGI  scripts  accomplish  the  interface  between  the  HTTP  server  and 
the  decision  technology  back  end  process.  Additional  support  functions  such  as:  secme 
storage  and  transfer  of  data  by  files,  and  transferring  output  data  back  to  the  consumer  will 
require  additional  server  software  and  will  be  dependent  on  the  provider’s  interface  require¬ 
ments.  These  additional  requirements  are  independent  to  the  DDSN  and  are  dependent  on 
the  provider’s  preferences  in  providing  the  service. 

b.  Personnel 

The  provider  is  responsible  for  the  functioning  of  the  information  system 
which  provides  the  decision  technology.  Programmers,  technicians,  support  personnel  are 
the  responsibilities  of  the  provider. 

4.  DDSS  Infrastructure 

A  Structured  Analysis  and  Design  Technique  (SADT)  model  better  known  as  an 
IDEF  0  model  was  developed  to  understand  the  activities  and  interaction  of  activities  of  the 
DDSS  better.  Appendix  B  illustrates  the  IDEFO  model  of  the  DDSS  activity  “Provide 
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Decision  Support  Technologies.”  A  functional  prototype  DDSS,  named  “DecisionNet”^  was 
developed  to  compare  and  contrast  different  design  options  and  to  gain  imderstanding  of  the 
total  DDSS  concept.  (King,  1995) 

a.  DDSS  Connectivity 

The  DDSS  entry  gateway  needs  to  have  a  direct  connection  to  the  global 
communication  network.  A  high  volume  of  data  is  sent  to  and  from  the  DDSS  by  the 
consumers  and  the  decision  technologies.  A  large  pipe  will  be  required  to  provide  reasonable 
response  time  to  the  consumers. 

b.  DDSS  Information  System 

The  DDSS  can  be  viewed  as  a  business  process  consisting  of  an  information 
system  consisting  of  a  variety  of  hardware,  software,  and  personnel  which  will  provide  all 
required  functionalities  to  users  of  the  DDSN.  Therefore,  the  activities  and  interaction  of 
activities  within  the  DDSS  will  heavily  influence  the  DDSS  infrastructure.  Modeling  of  the 
DDSS  identified  three  main  activities,  which  will  prominently  influence  the  infrastructure 
of  the  DDSS:  registration  of  users,  validation  of  technologies,  and  providing  an  interface 
for  the  technology. 

(1)  DDSS  Hardware.  The  current  DDSS  prototype  uses  a 
Macintosh  P7100  as  an  entry  HTTP  server  which  we  have  tasked  with  serving  DDSN 
introductory  information  and  maintaining  user  statistics.  A  UNIX  SPARC  2  is  called  to  do 
all  login  functions,  forms  processing,  search  mechanisms.  E-mail  functions  and  all  other 
back  end  processing.  This  configuration  demonstrates  that  a  distributed  server  configuration 
using  a  variety  of  hardware  could  support  the  DDSS.  However,  this  is  probably  an 
impractical  solution  due  to  hardware  and  software  maintenance  issues.  A  UNIX-BASED 
commerce  server  (SPARC  20)  with  all  server  software  installed  will  be  sufficient  as  an  initial 
gateway  server.  All  back  end  processing  will  be  supported  via  additional  platforms  as 
required.  The  determining  factors  in  selecting  the  hardware  configuration  will  be  based  on: 

^“DecisionNef  ’  is  a  WWW  based  functional  prototype,  which  allows  access  to  a 
distributed  network  of  modeling  and  decision  support  systems  over  the  Internet. 
DecisionNet”  is  available  for  use  at  URL:  http://dNet.as.nps.navy.mil/dNethome.html. 
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performance  measures,  required  processing  speeds,  number  of  simultaneous  users,  security 
requirements,  level  of  distributed  computing  environment,  ease  of  maintainability,  and  cost 
of  service  and  support. 

(2)  DDSS  Software.  Universities  have  built  and  distributed  most 
of  the  server  software  used  in  the  development  of  the  prototype  as  fi*ee  imsupported  fi-eeware. 
The  software  is  not  of  production  quality  and  is  consistently  receiving  configuration 
upgrades.  Freeware  is  appropriate  in  establishing  proof  of  concept,  but  the  DDSS  'will 
require  an  established  and  supported  server  software  package.  The  following  server  applica¬ 
tions  are  required  at  this  time:  DNS,  FTP,  HTTP,  SMTP,  Telnet.  Additional  Software 
applications  such  as  NNTP,  MMTP,  ListServe,  DBMS,  DDSS  middleware  will  be  required 
to  support  back  end  processes  and  support  functions  of  the  DDSS. 

(3)  DDSS  Personnel.  The  personnel  required  to  support  the  DDSS 
■will  be  largely  dependent  on  the  technical  staff  required  to  support  the  information  system. 
Network  managers  and  system  analysts  will  be  required  to  maintain  a  24-hour  information 
system.  Additional  personnel  classified  as  “Decision  Support  Specialist”  are  tasked  with 
classifying,  validation,  and  verification  of  technologies  registered  with  the  DDSS  and  later 
as  help  desk  consultants.  Programmers  will  be  needed  to  develop  technology  specific 
interfaces  and  middle-ware  required  for  automated  technology  registration  and  data 
translations.  Personnel  required  to  support  the  DDSS  should  decrease  as  functions  are 
automated  and  different  stages  of  development  are  realized.  Additional  help  desk  personnel 
will  be  required  to  help  in  setup,  execution,  and  monitoring  use  of  applications  during  the 
middle  stages  of  development. 

D.  SUMMARY 

The  DDSN  architecture  is  a  very  high  level  architecture  which  will  continue  to  evolve 
over  the  project  development  stages.  This  architecture  is  based  on  the  present  architecture 
of  the  WWW,  which  being  in  an  infancy  state  is  also  evolving.  Further  research,  enabling 
technologies,  and  development  of  the  DDSS  will  influence  the  architecture  of  the  DDSN. 
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It  is  evident  from  the  initial  architecture  that  further  research  and  development  will 
be  centered  around  the  DDSS  architecture  and  infrastructure.  However,  we  must  also 
establish  a  market  for  distributed  decision  support  technologies.  We  must  identify  enter¬ 
prises  and  functional  areas  that  need  this  type  of  technology  and  obtain  their  requirements. 
Consumers’  willingness  to  divulge  corporate  or  personal  data  to  a  distant  site  for  processing 
must  be  analyzed.  These  type  of  issues  concerning  the  providers  and  consumers  also  should 
be  considered  research  challenges.  Without  providers  and  consumers,  a  DDSN  does  not 
exist. 

This  chapter  provides  an  initial  architecture  framework  that  documents  the  ideas 
behind  the  DDSN  concept.  It  establishes  a  road  map  which  researchers  and  developers  can 
follow  to  continue  research  and  development  of  the  DDSN  ideas.  Since  the  DDSN  concept 
was  developed  in  an  academic  environment  the  initial  architecture  is  based  on  ideas  of  the 
initial  project  team  and  does  not  reflect  requirements  established  by  a  single  customer 
requiring  this  service. 
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V.  MODELING  AND  SIMULATION  IN  THE  DOD 


A.  INTRODUCTION 

Reductions  in  force  structure  and  annual  operating  expenses  have  placed  more 
emphasis  on  the  use  of  models  and  simulations  to  maximize  use  of  available  resources.  DoD 
believes  that  Modeling  and  Simulation  (M&S)  can  improve  military  capability  and  decision 
making  in  four  areas:  readiness,  modernization,  force  structure,  and  sustainability.  The  DoD 
M&S  vision  is  to  support  DoD  components  in  a  variety  of  functional  areas  by  developing, 
maintaining,  and  distributing  a  wide  range  of  models  and  simulations  to  support  their 
objectives.  Figure  5  illustrates  the  range  of  the  vision  for  M&S  in  the  DoD.  (DoD,  1994) 
(DoD,  1995) 


Additional  M&S  Dimemlons 

•  Lavel  of  Hesolutlori 

•  i>egnMi  of  Human  Participation 
«  Degree  of  Equipment  Healism 
•Time  Management  Method 

•  Time  Step  ResolutFon 

•  Degree  of  Distrtbution 

•  Computational  Complexity 


SpDn&oringi  OompaiMni 


Figure  5.  Range  of  M&S  in  DoD,  DoD  Master  Plan,  DoD  5000.59Paa 


The  Defense  Modeling  and  Simulation  Office  (DMSO)  was  established  to  coordinate  policy, 
establish  interoperability  standards  and  protocols,  promote  simulation  in  the  military 
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services,  and  to  establish  guidelines  for  coordinating  simulation,  war  gaming,  and  training. 
(U.S.  Senate,  1990)  The  DOD  Executive  Council  for  Modeling  and  Simulations  (EXCIMS) 
was  established  to  provide  the  Under  Secretary  of  Defense  (Acquisition  &  Technology) 
(USD  (A&T))  a  mechanism  to  establish  and  implement  DoD  policy,  initiatives,  standards, 
and  capabilities  to  enhance  (M&S)  in  the  DoD.  EXCIMS  is  comprised  of  DoD  Component 
representatives  and  is  chaired  by  the  Director,  Defense  Research  and  Engineering  (DDR&E). 
(DoD,  1994)  DoD  has  the  management  resources  in  place  and  must  now  bring  their  vision 
to  reality. 

This  chapter  discusses  objectives  of  the  DoD  M&S  Master  Plan  that  are  relevant  to 
the  concepts  of  the  DDSN,  identifies  ongoing  DoD  M&S  and  C4I  projects  that  are  similar 
and/or  related  to  the  DDSN  concept,  and  discusses  how  the  DDSN  concept  could  be  used  to 
support  DoD  fimctional  areas  with  decision  support  technologies. 

B.  DOD  M&S  MASTER  PLAN  OBJECTIVES 

The  DoD  M&S  Master  Plan  establishes  long  term  objectives  for  M&S  within  the 
DoD.  (DoD,  1995)  The  plan  is  broken  down  into  six  objective  areas  as  illustrated  in  Figure 
6.  Objective  one,  five,  and  six  of  the  master  plan  parallel  the  concept  of  the  DDSN.  DoD’s 
emphasis  is  on  the  use  of  simulations  for  decision  support,  while  the  DDSN  emphasis  is  on 
analytical  models.  The  common  objectives  are  discussed  below. 

1.  Common  Technical  Framework  for  Modeling  and  Simulation 

DoD  desires  a  common  framework  which  will  facilitate  interoperability  between 
models  and  simulations,  integration  of  M&S  Avith  C4I  systems,  and  increased  usage  and 
reuse  of  M&S.  Their  approach  is  to  dictate  a  high  level  architecture  and  to  standardize 
representations  of  data  wdth  which  all  DoD  models  and  simulations  will  conform.  While  the 
methodology  to  obtain  the  objective  is  different,  the  goals  are  similar  to  that  of  the  DDSN. 
The  DDSN  concept  establishes  a  multi-dimensional  taxonomy  of  objects  which  are  based 
on  the  inputs  and  outputs  of  the  application.  The  provider  declares  input  and  output  data 
formats  in  a  “Parameterized”  Format  Description  Language  (PFDL)  and  is  translated  by 
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agents  of  the  DDSS.  Format  conversions  are  done  as  required  to  allow  for  transfer  of  user 
data  and  interoperability  between  applications. 

2.  Establish  a  M&S  Infrastructure  to  Meet  Developer  and  User  Needs 
Goals  of  the  DoD  M&S  infrastructure  are  also  similar  to  that  of  the  DDSN.  The  DoD 
infrastructure  is  broken  into  five  components  defined  as  the  following  sub-objectives: 

a.  Field  M&S  Systems  in  Adequate  Numbers  to  Meet  End  User  Needs 

A  DoD  Inspectors  General  (IG)  inspection  conducted  in  March  of  1993 
substantiated  that  the  DoD  lacked  the  ability  to  effectively  and  efficiently  use  models  and 
simulations.  One  of  the  major  findings  was  that  applications  were  developed  as  stand  alone 
models  with  no  reuse  capability;  another  was  that  there  were  redundant  investments  in 
similar  systems.  An  estimated  800  million  dollars  could  have  been  saved  in  FY93  if  an 
effort  to  consolidate  systems  would  have  occurred.  (Mercer,  et  al.,  1994) 


In  an  effort  to  reduce  redundancy,  DoD  plans  to  identify  user  requirements 
for  M&S  within  five  functional  areas:  Education,  Training,  and  Military  Operations 
(ETMO),  Analysis,  Research  and  Development  (R&D),  Test  and  Evaluation  (T&E),  Projects 
and  Logistics  (P&L).  Once  user  requirements  are  identified,  DoD  will  plan  and  program  the 
fielding  and  interconnection  of  the  necessary  models  and  simulations  to  support  the  needs 
of  the  entire  DoD.  Unused  M&S  systems  will  then  be  phased  out  of  the  system. 

Identifying  requirements  for  a  single  user  is  a  difficult  task,  identifying 
requirements  of  multiple  users  over  five  different  functional  areas  seems  impossible.  It  could 
be  argued  that  this  is  an  unrealistic  objective  due  to  continually  changing  requirements.  The 
DDSN  concept  takes  somewhat  of  a  reversed  position  on  achieving  this  objective.  Instead 
of  reducing  the  applications  available,  all  M&S  resources  would  be  made  available,  giving 
the  user  more  flexibility  in  choosing  and  using  the  tools  to  support  the  mission. 

b.  Validation,  Verification,  and  Accreditation  (W&A) 

DoD  realizes  that  VV&A  and  Verification,  Validation,  and  Certification 
(VV&C)  is  required  to  achieve  confidence  in  the  use  of  M&S  by  the  user  community. 
Standards,  policies,  and  procedures  need  to  be  developed  to  achieve  VV&A  and  W&C. 
The  DDSN  concept  shares  the  same  concern  for  VV&A  of  technologies  made  available  on 
the  DDSN.  W&A  is  initially  the  responsibility  of  the  provider  of  the  technology,  however 
the  DDSN  will  need  a  process  to  verify  the  providers  VV&A. 

c.  Repositories 

To  enhance  development,  use,  and  increase  awareness  of  models  and  simula¬ 
tions,  DoD  is  developing  a  resource  library.  An  Interim  M&S  Resource  Library  (IMSRR) 
is  presently  operational  with  a  WWW  interface  at  Fort  Huachuca."*  The  goal  of  this  library 
is  to  provide  developers  and  users  of  M&S  with  “timely,  verified,  and  validated  data, 
metadata,  algorithms,  models,  simulations,  and  tools.”  This  repository  allows  users  to  leam 
about  a  technology  by  reviewing  backgroxmd  information  (e.g.,  data  source,  W&A/C 

'‘Available  at  URL:  http://huachuca-jdbe.army.mil;  hosted  by  Joint  Data  Base 
Elements  for  Modeling  &  Simulation  (JDBE). 
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history,  algorithms  used,  developer).  The  user  can  then  decide  if  the  technology  is  useful  and 
can  retrieve  the  technology  for  use.  This  type  of  library  may  support  a  developer,  but  will 
probably  not  be  used  by  an  average  user  of  M&S.  The  arguments  for  developing  a  DDSN 
established  in  Chapter  II  support  this  position.  An  average  user  wants  to  use  a  technology 
and  does  not  want  to  worry  about  the  configuration  and  management  of  it. 

The  DDSN  repository  is  similar,  but  is  described  as  an  executable  electronic 
library  of  decision  technologies.  The  DDSN  repository  could  be  used  as  both  a  reuse  and 
use  library.  This  would  benefit  both  the  developer  and  the  user  of  M&S.  The  developer 
could  review  the  backgroimd  material  and  also  execute  the  technology  to  determine  if  the 
functionality  of  the  technology  met  the  requirements.  The  user  would  access,  provide  data, 
and  use  the  technology  as  required,  without  obtaining  the  technology  software. 

Another  problem  with  the  IMSRR  and  other  catalogs  of  M&S  technologies 
is  the  storage  of  metadata  concerning  the  technology.  Once  the  information  is  provided,  it 
is  immediately  outdated.  In  today’s  distributed  environment  this  information  should  be 
dynamic.  When  a  model  or  simulation  technology  is  modified,  all  repositories  should  also 
reflect  that  change.  The  IMSRR  and  M&S  catalogs  require  background  information  be 
managed  by  the  facilitator  of  the  repository,  not  the  developer  of  the  technology.  Because 
technologies  are  always  changing  and  improving,  the  developer  should  be  made  responsible 
for  this  information. 

d.  Communications 

DoD  presently  has  the  Defense  Simulation  Internet  (DSI)  in  place  and 
believes  that  by  increasing  reliability  and  bandwidth  that  DSI  can  be  transitioned  into  an 
operational  service  for  the  distribution  of  models  and  simulations.  The  current  defense 
information  infi-astructure,  commercial  services,  and  radio  frequency  communications  will 
be  utilized  to  link  DSI  with  C4I  systems.  This  will  allow  M&S  support  to  any  DoD  user, 
anytime,  anywhere.  The  DDSN  has  the  same  goal;  decision  support  to  any  user,  anytime, 
anywhere.  The  same  type  of  communication  requirements  exist  for  the  implementation  of 
the  DDSN. 
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Coordination  Center 


e. 

The  DoD  is  establishing  a  M&S  Coordination  Center  (MSCC).  This  center 
will  provide  support  to  all  users  (Cincs,  Services,  Agencies,  Project  Managers)  of  all 
functional  areas.  The  MSCC  will  be  responsible  for  coordinating,  advising,  and  establishing 
use  of  world-wide  distributed  simulation  capabilities.  Due  to  the  size  and  complexity  of  this 
M&S  network,  human  assistance  will  be  required  to  coordinate  usage,  assist  users,  and  to 
make  M&S  systems  available. 

The  DDSN  also  requires  an  organization  of  this  type,  but  of  a  much  smaller 
scale.  By  using  software  agents  it  is  envisioned  that  the  resources  required  to  provide  some 
of  these  functions  can  be  automated.  The  best  example  of  this  is  defined  by  the  level  three 
configuration  of  the  DDSS.  At  level  three  the  user  merely  states  the  problem  and  the  DDSS 
would  automatically  identify  the  best  technology  to  assist  the  user. 

3.  Share  the  Benefits  of  M&S 

This  objective  within  the  DDSN  concept  is  to  allow  a  diverse  set  of  users  access  to 
a  variety  of  decision  support  technologies  with  minimal  overhead.  However,  DoD  defines 
this  objective  by  three  sub-objectives: 

a.  Quantify  the  Impacts  of  M&S 

In  an  attempt  to  assess  the  value  of  M&S,  DoD  desires  to  establish  quantita¬ 
tive  measures  which  illustrate  the  utility  of  M&S  within  functional  areas.  While  this  is  not 
a  functional  goal,  it  serves  to  justify  and  educate  agencies  that  are  ignorant  of  M&S 
capabilities. 

b.  Education  of  M&S  Users 

New  users  of  M&S  will  require  education  and  training  in  establishing  and 
using  M&S  resources.  DoD  plans  to  conduct  seminars  and  workshops  to  expand  user  aware¬ 
ness  across  the  M&S  community.  Since  the  DDSN  is  WWW  based,  the  training,  education 
and  dissemination  of  information  is  supplementary  to  the  system.  The  DDSN  also  allows 
for  a  serendipity  learning  environment;  the  user  may  have  no  idea  that  an  application  exist, 
but  by  browsing  the  repository  may  find  a  suitable  technology  to  support  a  known  or  future 
requirement. 


40 


c.  Technology  Transfer  with  Other  Agencies 
DoD  desires  to  stimulate  technology  transfer  of  M&S  between  other  govern¬ 
ment  agencies,  private  industry,  universities,  and  other  nations.  Traditional  methods  such 
as  demonstrations  and  meetings  are  being  planned  to  accomplish  this  objective.  The  transfer 
of  technology  is  also  built  into  the  DDSN.  Developers  can  learn  about  and  test  an  applica¬ 
tion  maintained  in  the  executable  repository  of  the  DDSS.  If  additional  information  is 
required  about  a  technology,  developers  can  go  offline  and  discuss  relevant  issues. 

C.  DOD  M&S  AND  C4I  PROJECTS 

There  are  a  few  projects  presently  being  researched  and  developed  within  the  DoD 
which  demonstrates  the  integration  of  M&S  with  C4I.  A  few  of  these  are  discussed  below. 

1.  Distributed  Interactive  Simulation  (DIS)/Advanced  Distributed  Simula¬ 
tion  (ADS) 

Originally  sponsored  by  Defense  Advanced  Research  Projects  Agency  (DARPA)  and 
known  as  the  SIMNET  (SIMulation  NETwork)  program,  this  concept  has  evolved  into  DIS, 
ADS,  and  now.  High  Level  Architecture  (HLA).  DIS  is  the  infrastructure  which  implements 
the  concepts  of  ADS.  The  ADS  concept  is  to  synthetically  create  large  environments  so 
users- can  interact  in  real-time  simulations.  The  HLA  architecture  creates  a  framework  for 
developers  and  policy  makers  to  address  simulation  design  and  implementation  issues. 

The  initial  focus  of  this  technology  has  been  in  training,  however  DIS/ADS  is  seen 
as  a  tool  for  evaluating  new  concepts  in  a  variety  of  military  fimctional  areas.  The  Defense 
Science  Board  (DSB)  believes  tiiat  this  technology  will  also  aid  in  research  and  development, 
prototyping  of  systems  and  testing  of  weapon  systems  in  synthetic  environments.  These 
environments  or  virtual  worlds  are  linked  electronically  to  give  a  shared  representation  of 
space.  Linkage  to  other  sites  allows  real  time  interaction,  with  man-in-the-loop  affecting  the 
outcome.  The  two  distinct  characteristics  of  this  technology  are  that  the  simulations  are 
physically  separated  and  they  must  be  electronically  connected  to  allow  for  a  common 
picture  of  the  environment  space.  This  allows  all  nodes  to  act,  interact,  influence  and 
respond  within  the  same  battle  space.  (Mercer,  et  al.,  1994) 
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2.  Common  Operational  Modeling  Planning  and  Simulation  Strategy 
(COMPASS) 

The  goal  of  COMPASS  is  to  “bring  modeling  and  simulation  services  and  collabora¬ 
tive  planning  tools  to  C4I.”  A  common  messaging  environment  using  middleware  is  used 
to  extend  DIS  protocols  from  modeling  and  simulation  to  C41  systems.  COMPASS  provides 
an  Application  Program  Interface  (API)  which  acts  as  a  presentation  layer  and  translation 
layer  between  legacy  planning  systems.  This  allows  for  the  use  of  proven  planning  systems 
to  be  interfaced  using  commercial  distributed  computing  applications.  The  Distributed 
Collaborative  Planning  (DCP)  applications  (whiteboard,  video  conferencing,  shared  overlay 
management)  allow  planners  to  collaborate  on  plan  development.  The  modeling  and 
simulation  tools  allow  all  planners  to  preview  composite  mission  and  simulated  mission 
rehearsals.  This  program  leverages  current  investments  (legacy  planning  systems),  allows 
collaboration  between  geographically  dispersed  planners,  and  allows  for  a  preview  of  the 
plan  developed.  (Nayfack,  1995) 

3.  Joint  Task  Force/Advanced  Technical  Demonstration  (JTF/ATD) 

The  JTF  is  the  crisis  response  team  for  the  DoD  and  is  required  to  respond  to  a 
variety  of  situations.  The  idea  of  the  JTF/ATD  is  to  provide  the  JTF  Commander  with  the 
right  tools  to  create  plans,  analyze  courses  of  actions,  communicate  plans,  and  to  enhance 
perception  of  the  current  situation.  The  JTF/ATD  is  an  Advanced  Research  Projects  Agency 
(ARP A)  project  which  envisions  “a  mobile  distributed  network  of  graphic  planning  cells 
sharing  a  common  reasoning  infrastructure  and  architecture.”  (Krai,  1995)  This  environ¬ 
ment  would  allow  for  concurrent  assessment,  plan  generation,  scheduling,  and  analysis 
processes  between  the  Commander  Joint  Task  Force  (CJTF),  CJTF  components,  and 
supporting  Commander-in-Chiefs  (CINCS).  The  architecture  is  based  on  a  COE  and  shared 
object  classes  with  flexibility  in  adapting  to  current  needs  by  integrating  new  software 
modules.  Flexibility  is  established  by  developing  new  software  modules  for  different 
situations.  A  module  may  take  between  two  person  hours  to  a  few  person  weeks  to  develop 
and  integrate  with  the  system.  (Erman,  et  al.,  1994) 
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D.  DOD  AND  THE  DDSN  CONCEPT 


1.  Overview 

As  identified  by  the  discussion  of  the  C4I/M&S  projects,  it  is  evident  that  the  DoD 
is  moving  towards  a  proprietary  system  to  integrate  M&S  with  C4I.  Developing  a  proprie¬ 
tary  system  will  allow  for  an  efficient  and  reliable  method  to  interface  required  M&S 
applications.  A  HLA  must  be  established  and  maintained  that  developers  and  policy  makers 
must  conform  to.  Developers  must  conform  to  these  standards  and  data  conventions  to 
guarantee  interoperability  and  information  transfer  between  applications.  New  M&S 
applications,  will  be  developed  easily  as  they  will  use  standardized  information  definitions. 
Preferred  stove  pipe  applications  will  be  re-engineered  or  middleware  will  be  developed  to 
allow  for  their  use  in  this  architecture. 

The  DDSN  concept  allows  for  applications  to  be  built  independent  of  a  standardized 
architecture  and  allows  for  transfer  of  information  by  allowing  middleware  to  translate  the 
input  and  ouQ)ut  data.  While  it  can  be  argued  that  the  translation  of  middleware  is 
maintenance  intensive  and  promotes  building  of  stove  pipe  applications,  new  technology  is 
envisioned  that  \vill  dispute  this  argument.  Software  agents  are  becoming  popular  in 
automating  processes  that  usually  require  extensive  interface  and  communication.  By 
developing  these  software  agents  to  automatically  register  independent  technologies  and 
build  required  interfaces,  the  maintenance  of  such  applications  should  be  reduced. 

2.  DDSN  Areas  of  Use  in  the  DoD 

It  is  the  authors  opinion  that  the  DDSN  is  not  a  concept  that  would  replace  a 
proprietary  DoD  M&S  distributed  system,  but  one  that  would  support  or  complement  it.  The 
proprietary  system  should  allow  a  method  to  access  and  use  other  M&S  resources  to  assist 
in  the  decision  making  process  in  the  event  a  tool  or  data  is  not  available.  Under  the  DDSN 
concept,  a  large  repository  of  decision  technologies  from  universities,  research  institutions, 
industry,  and  individuals  would  be  made  available  to  the  DoD  for  use  as  required.  Military 
schools,  military  analyst,  acquisition  professionals,  and  individuals  could  all  benefit  by 
having  access  to  a  repository  of  such  technologies.  A  discussion  on  how  these  areas  could 
benefit  from  the  DDSN  concept  is  provided. 
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a.  Military  Schools 

Students  at  graduate,  mid-level,  and  upper  level  schools  could  share  tech¬ 
nologies  that  were  developed  by  students  of  odier  schools  and  curriculums.  A  lot  of  time  is 
wasted  developing  models  and  algorithms  which  have  previously  been  developed  to  support 
another  students  or  professors  work.  A  DDSN  would  increase  awareness  and  use  of  existing 
technologies  from  all  Colleges  and  Universities  abroad.  These  technologies  could  also  serve 
as  starting  points  for  re-engineering  or  development  of  new  applications. 

b.  Acquisition  Professionals 

The  use  of  Models  and  Simulations  within  the  acquisition  process  presently 
supports  all  communities  involved  in  the  development,  design,  manufacturing,  and  testing 
of  the  system  being  acquired.  A  variety  of  models,  simulations  and  supporting  data  is 
required  to  conduct  mission  area  assessments,  mission  needs  analysis,  cost  and  operational 
effectiveness,  measures  of  effectiveness,  and  measures  of  performance.  The  list  of  analysis 
tools  available  to  support  a  program  manager  is  quite  extensive.  The  data  sets,  models  and 
analytical  tools  required  by  all  acquisition  activities  could  be  provided  for  use  in  a  distri¬ 
buted  environment  as  outlined  by  the  DDSN  architecture.  All  activities  could  share  the  same 
supporting  data  and  analytical  tools  from  the  requirements  to  the  implementation  stages  of 
the  project  life  cycle.  If  supporting  data  was  changed,  it  would  only  have  to  be  changed  at 
one  location,  reducing  the  chance  of  errors  in  analysis.  This  would  also  promote  reuse  by 
making  applications  available  for  future  projects. 

c.  Military  Analyst 

The  complexity  of  the  modem  battlefield  and  the  amount  of  information 
available  to  the  military  commander  has  increased  reliance  on  supporting  staff  and  military 
analyst.  Analytical  support  is  being  provided  to  field  commanders  by  establishing  help  desk 
or  anchor  desk  in  specific  ftmctional  areas  (e.g.,  logistics,  intelligence,  meteorology, 
manpower).  These  help  desk  are  located  in  the  rear  areas  and  are  manned  by  professional 
analyst  and  contain  analytical  tools  to  support  the  commanders  decision  making  process. 
High  speed  communications  are  used  to  transmit  unique  data  and  request  for  analytical 
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support  from  the  commander,  the  analyst  will  then  use  a  variety  of  tools  to  compare  contrast 
and  give  feedback  on  the  request. 

Today’s  military  performs  a  variety  of  missions  which  are  categorized  as 
“Operations  Other  Than  War.”  Commanders  are  often  confronted  with  scenarios  that  current 
military  doctrine  and  tactics  do  not  address.  Analytical  tools  and  information  unique  to  these 
new  missions  may  also  not  be  available.  The  DDSN  concept  would  allow  analyst  in  a 
variety  of  disciplines  to  connect  to  a  repository  of  decision  technologies  outside  of  DoD  that 
may  support  these  operations.  In  addition  to  the  predefined  tools  that  have  been  established 
to  support  established  doctrine  and  tactics,  a  new  dimension  of  support  applications  can  be 
made  available  to  combatant  commanders  through  help  desk  or  accessed  directly  by  the 
Commander  in  the  field. 

d.  Individuals 

Personnel  are  consistently  identified  as  the  most  important  resource  in  the 
military  services.  Many  support  services,  such  as  relocation  specialist,  family  support,  finan¬ 
cial  support  and  retirement  services  are  required  to  achieve  and  maintain  a  high  degree  of 
morale  by  service  members.  These  services  may  or  may  not  be  used  by  service  members, 
but  are  made  available,  in  case  they  do.  It  is  believed  that  DoD  personnel  could  also  benefit 
from  having  access  to  decision  technologies  which  assist  them  in  making  career  decisions 
as  well  as  personal  decisions  that  influence  their  everyday  life.  Some  of  the  services  that  are 
presently  presented  by  clinics  and  seminars  could  be  made  available  using  the  WWW  and 
DDSN  technology.  This  would  allow  personnel  to  obtain  information  and  to  use  decision 
support  services  at  their  own  convenience.  This  would  reduce  some  of  the  overhead 
presently  associated  with  these  type  of  support  activities. 

There  are  probably  many  other  situations  in  which  the  DDSN  concept  could 
be  employed  within  the  DoD.  Basically,  any  organization  that  requires  assistance  in  making 
decisions  could  benefit  from  this  technology. 
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E.  CONCLUSIONS 


The  DoD  has  generated  a  vision  to  effectively  and  efficiently  use  M&S  to  support  a 
conglomerate  of  mission  requirements.  The  integration  of  M&S  to  C4I  will  allow  decision 
makers  in  a  variety  of  functional  areas  to  assess  units  performance  and  capabilities,  develop 
and  evaluate  operational  plans,  and  conduct  what-if  analysis  in  academic,  training,  and 
operational  environments  to  achieve  this  vision,  DOD  must: 

•  Develop  a  HLA  architecture  which  will  mandate  common  standards  and 
conventions  to  be  used  in  future  M&S  system  and  application  development. 

•  Re-engineer  existing  preferred  stove  pipe  systems  that  are  considered  mission 
essential  to  function  within  the  new  architecture. 

•  Identify  requirements  of  functional  areas  to  be  supported. 

•  Develop  and  maintain  applications  required  to  support  all  functional  areas. 

•  Develop  and  maintain  the  technical  architecture  and  infrastructure  to  support 
the  integration  of  M&S  with  C4I. 

This  architecture  will  allow  chosen  sites  the  use  of  selected  and  predetermined  M&S 
applications  to  support  missions  identified  by  functional  user  requirements.  While  the 
architecture  provides  a  mechanism  to  share  M&S  resources,  it  also  creates  a  high  level  of 
system  and  application  maintenance  overhead.  A  MSCC  will  be  required  to  assist  users  and 
coordinate  usage.  Additionally,  all  sites  will  be  required  to  maintain  a  suite  of  software  that 
is  required  for  the  transfer  of  information  and  to  achieve  interoperability  between  applica¬ 
tions. 

While  the  goals  of  the  DoD  vision  and  the  concepts  of  a  DDSN  are  the  same,  the 
target  environment  is  different.  DoD’s  vision  provides  a  designated  set  of  users  within 
functional  areas,  a  predetermined  set  of  models  and  simulations.  [The  DDSN  idea  allows 
all  users  of  a  common  network  access  to  an  undetermined  amoimt  of  decision  technologies; 
limited  by  availability  only].  Use  of  the  DoD  M&S  network  would  require  users  to  have 
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access  to  a  designated  platform  which  is  configured  for  use  of  the  M&S  network.  The 
DDSN  concept  allows  any  user  with  a  personal  computer  to  become  an  instance  of  an 
application  running  on  a  super  computer  with  limited  software  requirements. 

The  dynamic  scenarios  which  components  of  the  DoD  support  will  require  flexibility 
in  the  t5q)e  of  applications  made  available.  The  COE  envisioned  will  provide  applications 
to  support  decision  makers  with  well  defined  and  understood  problem  situations.  A 
mechanism,  such  as  that  proposed  by  the  JTF/ATD  will  be  required  to  allow  for  the 
expedient  development  and  interface  of  modules  to  assist  decision  makers  in  diverse  and 
unknown  situations.  The  DDSN  architecture  could  compliment  the  simulations  and  models 
available  within  the  M«&:S  COE;  allowing  immediate  access  and  use  of  models  and 
simulations  that  may  only  be  used  sporadically,  under  unique  situations. 
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VI.  CONCLUSIONS 


A.  THESIS  SUMMARY 

This  thesis  introduced  a  new  concept  for  integrating  decision  support  technologies 
with  global  computer  networks.  The  main  objective  of  this  concept  is  to  provide  decision 
support  technologies  to  users  of  a  global  heterogeneous  network  with  minimal  standards  and 
conventions  dictated.  The  architecture  and  infrastructure  of  the  DDSN  provides  documen¬ 
tation  for  further  research,  development,  and  implementation  of  this  concept.  The 
architecture  and  infrastructure  identified  in  this  thesis  is  based  on  the  ideas  of  the  WWW  and 
will  continue  to  evolve. 

The  DoD  also  realizes  that  the  integration  of  M&S  with  computer  networks  will 
provide  for  better  use  of  M&S  resources.  They  envision  integrating  M&S  with  C4I  to 
increase  availability,  shareability,  and  reuse  of  M&S  applications  between  a  variety  of 
functional  areas.  Their  infrastructure  to  achieve  this  is  based  on  a  COE  and  mandating 
standards  and  conventions  in  the  development  of  M&S  applications.  This  infrastructure  will 
guarantee  interoperability  between  applications,  but  will  restrict  access  to  those  applications 
identified  by  functional  area  requirements.  The  DDSN  infrastructure  can  augment  the  DoD 
infrastructure  by  allowing  users  to  use  decision  technologies  developed  outside  of  the  COE. 
This  will  allow  users  to  access  technologies  that  may  only  be  required  for  a  specific  situation. 

B.  AREAS  OF  FURTHER  RESEARCH 

The  general  nature  of  this  thesis  has  resulted  in  identifying  a  variety  of  topics  of 
which  will  require  further  research.  Further  research  of  the  DDSN  concept  falls  into  three 
general  categories:  further  development  of  the  DDSS,  identifying  or  developing  applications 
to  demonstrate  the  functionalities  of  the  architecture,  and  developing  a  plan  for  managing  the 
DDSN  infrastructure. 

1.  Future  Development  of  the  DDSS 

Decision  Net,  the  DDSS  prototype,  has  proven  the  ability  to  execute  independent 
technologies  remotely  using  WWW  technology.  The  next  development  stage  of  the  DDSS 
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will  allow  for  automatic  registration  and  interactivity  between  exclusive  applications.  Before 
this  software  can  be  developed,  a  taxonomy  of  decision  technologies  needs  to  be  established 
and  an  algorithm  to  classify  decision  technologies  must  be  created.  A  determinant  factor  in 
user  satisfaction  of  the  DDSN  will  be  the  ability  to  find  the  correct  application  for  a  given 
situation.  The  taxonomy  and  classification  mechanism  will  be  essential  in  developing  an 
intelligent  search  agent  to  locate  applications  best  suited  to  support  a  users  problem 
definition. 

The  development  of  the  middleware  which  provides  for  the  translation  of  inputs  and 
outputs  to  achieve  interoperability  is  based  on  theory  and  a  proof  of  concept  is  required. 
Further  research  must  prove  PFDL  and  address  the  limitations  of  the  language.  Intelligent 
software  agents  need  to  be  developed  which  will  allow  for  the  expedient  translation  of  data 
to  the  new  data  type.  Methods  to  store,  identify,  translate,  and  deliver  these  data  objects 
must  be  developed  and  implemented. 

2.  Developing  Applications  to  Demonstrate  DDSN  Potential 

Users  of  the  DDSN  will  require  confidence  of  the  applications  made  available, 
providers  must  also  realize  the  benefits  of  this  technology  before  they  will  want  to  register 
their  technologies.  An  assortment  of  killer  applications,  which  illustrates  the  benefits  to  all 
users  and  capabilities  of  the  network  needs  to  be  identified  and  implemented.  These 
applications  should  be  real  world  applications  that  can  be  used  within  a  functional  area.  A 
possible  area  of  interest  may  be  witiiin  command  and  control. 

3.  Develop  a  Management  Plan  for  the  DDSN  and  the  DDSS  Infrastructure 

The  management  facet  of  the  DDSN  needs  to  be  researched  since  the  DDSN  can  be 

considered  as  a  service  oriented  business.  As  such,  a  management  plan  to  ensure  satisfaction 
of  service  is  required.  The  management  plan  should  address  all  legal,  financial,  and 
regulatory  concerns  of  the  system,  identify  performance  measures,  optimal  system 
configurations  to  meet  those  performance  measures,  and  quality  control  methods  employed 
to  assure  satisfaction. 

In  developing  the  management  plan,  potential  barriers  will  need  to  be  addressed  and 
resolved.  An  example  is  the  issue  of  software  licensing  of  distributed  applications.  Will  new 
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legislation  need  to  be  introduced  to  allow  for  multiple  users  to  access  and  use  a  software 
application  running  on  the  software  owners  machine?  Charge  back  mechanisms  must  also 
be  identified  and  a  method  to  monitor  usage,  initiate  billing,  and  receipt  of  payment  from 
users  must  be  established.  Additionally  the  system  must  provide  for  a  certain  degree  of 
performance  standards  (security,  reliability,  and  availability)  to  all  users  of  the  network. 
Server  and  network  configuration  management  issues  need  to  be  addressed,  metrics  to 
measure  performance  standards  identified,  and  methods  to  provide  security  of  corporate  data 
established. 

C.  CONCLUSIONS 

This  thesis  established  proof  of  concept  for  the  distribution  of  decision  support 
technologies  to  users  of  a  global  network.  The  initial  architecture  and  proposed  infra¬ 
structure  identifies  the  DDSS  as  the  link  pin  of  the  DDSN  idea.  The  DDSS  provides  the 
majority  of  functions  which  allow  for  access,  execution,  and  interoperability  between  all 
entities  of  the  network.  The  DDSN  concept  is  dependent  heavily  on  the  technical  develop¬ 
ment  of  the  DDSS,  however  it  is  also  dependent  on  developing  an  electronic  market  of 
decision  support  services.  Consumers  and  providers  of  decision  technologies  must  want  to 
use  the  services  of  this  market.  Government  interest  in  Nil,  and  the  expodential  growth  of 
the  WWW  suggest  that  electronic  commerce  is  the  wave  of  the  future.  The  DDSN  concept 
is  one  way  in  which  the  decision  sciences  can  ride  this  wave. 

The  initial  architecture  develops  the  DDSN  concept  as  a  global  resource,  used  by  all 
who  have  access  to  the  Internet,  however,  it  is  felt  that  the  concept  is  also  suitable  at  an 
enterprise  level.  A  computer  integrated  enterprise  is  based  on  the  integration  of  information 
and  decision  logic  to  achieve  functional  synergies.  A  DDSN  would  provide  access  to  the 
same  corporate  data  as  well  as  decision  aides  required  to  process  this  information.  Decision 
makers  could  use  the  same  decision  aides  which  would  enhance  decision  logic.  Each 
corporation  would  maintain  a  DDSS  which  would  also  allow  for  accoxmtability,  user 
availability,  and  reduced  maintenance  cost  of  decision  technologies  for  the  corporation. 
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The  DoD  evidently  expects  the  use  of  M&S  to  increase  readiness  and  reduce  wasted 
assets  in  the  DoD.  DoD  has  traditionally  used  simulations  in  war  gaming,  virtual  weapon 
system  trainers,  and  live  simulations  in  a  training  environment.  Models  and  decision  support 
systems  have  traditionally  been  developed  to  support  specific  requirements.  DoD  is  in  the 
process  of  building  a  M&S  network  which  will  meet  the  known  requirements  of  five  fimc- 
tional  areas  and  allow  for  interaction  between  all.  It  is  felt  that  the  DDSN  idea  can  augment 
this  network  by  making  additional  technologies  available  to  all  users  of  DoD. 
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GLOSSARY  (DEFINITIONS) 


Architecture: 


Consumer: 


Distributed  Decision 
Support  Network  (DDSN): 


Distributed  Decision 
Support  Server  (DDSS): 


Infrastructure: 


Network: 


Provider: 


The  structure  of  components  in  a  system,  their  inter¬ 
relationships,  and  principles  and  guidelines  governing  their 
design  and  development  over  time. 

Any  person  or  organization  who  is  in  the  market  for 
computational  decision  support  services. 


A  computer  network  which  allows  for  the  distribution  of 
decision  support  applications  over  a  global  network;  a  DDSN 
consist  of  a  computer  network,  providers  of  decision 
technologies,  consumers  of  decision  technologies,  and  the 
(DDSS). 


Provides  the  mechanisms  which  allow  users  to  register,  search 
for,  connect  to,  and  execute  a  decision  technology.  The 
DDSS  is  comprised  of  hardware,  software,  and  the  personnel 
assets  which  allows  for  the  functionality  of  the  DDSN. 

Resources  used  to  achieve  desired  functionalities  of  a  system 
(Personnel,  hardware,  software,  communications). 

Allows  for  the  physical  transfer  of  data  and  the  seamless 
interaction  between  different  t5^es  of  platforms. 

Organizations,  developers  and/or  individuals  who  desire  their 
decision  technology  to  be  executable  over  the  network. 
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APPENDIX  A.  ENABLING  TECHNOLOGIES 


A  variety  of  technologies  will  have  significant  impact  on  the  development  of  the  DDSN 
concept.  This  appendix  identifies  technologies  by  discussing  general  trends  and  briefly 
discussing  each  technology. 

A.  TRENDS 

The  use  and  performance  of  information  systems  technologies  have  increased  by  30- 
50%  percent  per  aimum  over  the  past  two  decades.  If  this  continues  more  than  1000  MIPS 
and  hundreds  of  megabytes  of  memory  in  workstations,  supported  by  billions  of  bytes  of 
local  storage  will  be  available  at  the  same  cost  of  today’s  high-end  workstations. 

Communications  bandwidth  capacity  exceeding  1+  Gbps  is  available  today.  This  will 
give  the  consumer  the  bandwidth  on  demand  required  for  high  resolution  multimedia. 

Information  search  and  retrieval  capabilities  available  in  client/server  environments 
are  allowing  consumers  to  find  the  information  available  over  the  global  networks.  The 
increase  in  demand  from  users  for  new  tools  to  expedite  information  retrieval  will  be 
eventually  led  to  intercormectivity  and  interoperability  of  data  and  software  applications. 
Distributive  Collaborative  Planning  tools  will  be  the  norms  on  most  desktop  environments. 
This  will  allow  for  interaction  for  planning  and  telecommunications. 

Mass  storage  capacities  will  continue  to  increase  with  decreased  cost.  Today,  hard 
disk  drive  mass  storage  can  be  purchased  at  $1  per  megabyte  (MB).  New  storage 
technologies  will  emerge,  lowering  cost. 

Multi-level  security  (MLS.)  continues  to  be  a  serious  topic  and  will  require  further 
research.  Some  organizations  will  have  accredited  MLS  systems.  A  US  Government-wide 
MLS  policy  does  not  exist  and  will  probably  not  be  developed  for  some  time.  Providing 
security  of  information  will  be  a  necessity  for  service  providers  of  a  global  network. 

The  use  of  Object-Oriented  Technologies  (OOT)  will  expand  into  software 
development,  operating  systems,  and  database  management. 

The  use  of  Virtual  Reality  is  becoming  popular  in  developing  user  interfaces  and 
modeling  techniques.  Interactive  simulations  allow  for  geographically  distributed  users  to 
interface  and  to  influence  the  enviromnent  for  which  they  are  acting.  This  technology  is 
available  presently  to  high  end  computing  systems  and  require  dedicated  networks.  The 
Virtual  Reality  Modeling  Language  (VRML)  vision  is  to  bring  interactive  3D  to  the  Internet 
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via  the  WWW.  This  may  influence  the  use  of  3D  models  and  simulations  at  a  lower  level 
of  computing. 

B.  COMMUNICATIONS 

Significant  advances  in  networking  and  long-haul  communications  technologies  are 
expected.  Local  Area  Networks  (LANs),  such  as  the  10  Megabits  per  second  (Mbps) 
Institute  of  Electrical  and  Electronics  Engineers  (IEEE)  802.3  Ethernet  and  16  Mbps  IEEE 
802.5  token  ring  are  commodity  items  available  worldwide  today.  Public  packet-switched 
Wide  Area  Networks  (WANs)  are  operated  in  all  industrialized  countries.  Large  private 
networks  in  both  the  Government  and  commercial  sectors  are  starting  to  use  T1  (1.544 
Mbps)  and  T3  (45  Mbps)  transmission  circuits.  Asynchronous  Transfer  Mode  (ATM),  and 
Synchronous  Optical  Network  (SONET)  will  dominate  both  Government  and  public-sector 
communications  networks. 

C.  INFORMATION  SYSTEMS 

Information  systems  are  encomposing  more  users.  Workstations  and  personal 
computers  are  now  interconnected  allowing  access  to  better  resources  and  sharing  of 
information.  Client/Server  technology  and  the  Distributed  Computing  Environment  (DCE) 
are  allowing  for  the  distribution  of  data,  display,  and  functional  processing  throughout  the 
network.  Client  server  technology  is  currently  being  implemented,  while  DCE  is  still 
immature  and  in  the  experimental  stages. 

D.  SECURITY 

Several  security  technologies  can  be  used  to  provide  information  security  services 
such  as  data  confidentiality,  data  integrity,  access  control,  identification  and  authentication, 
nonrepudiation,  and  availability.  Service  providers  will  have  to  guarantee  security  of 
consumers  data  if  electronic  commerce  will  be  accepted  by  the  populous  general.  MLS  will 
be  required  to  achieve  true  interoperability  between  users  with  different  security 
classifications;  both  data  and  information  systems.  Labeling,  storage,  and  processing  of 
data,  write  up  technologies,  and  separation  of  environments  make  MLS  a  hard  nut  to  crack. 

E.  OBJECT-ORIENTED  TECHNOLOGIES 

Obj  ect-oriented  technologies  (OOT)  are  emerging  as  a  group  of  technologies  that  will 
allow  information  systems  to  be  reusable,  interoperable,  and  portable.  The  technology  is 
demonstrating  significant  cost  and  time  savings  in  commercial  and  government  trials, 
including  military.  The  emerging  work  from  these  efforts  form  the  basis  for  the  full  life  cycle 
of  software;  they  support  system  development  and  data  management.  Areas  of  OOT  that 
will  probably  effect  the  development  of  the  DDSN  concept  are :  object-oriented  analysis  and 
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design  (OOA/OOD),  object-oriented  operating  systems  (000s),  object-oriented  program¬ 
ming  languages  (OOPLs),  object-oriented  database  management  systems  (OODBMSs),  and 
Object  Management. 

F.  COMPRESSION  TECHNIQUES 

Technologies  exist  to  compress  digital  images  and  video  to  a  fraction  of  their  original 
size  for  storage  and  transmission.  Methods  that  achieve  high  compression  ratios  remove 
some  data  to  achieve  smaller  data  files.  The  use  of  simulations  for  playback  or  possibly 
interactive  simulations  will  require  large  compression  ratios.  The  Virtual  Reality  Modeling 
Language  (VRML)  presently  uses  compression  technology  to  transmit  3D  worlds  to  users 
of  the  Internet.  The  resolution  required  by  the  application  and  the  user  will  determine  the 
type  of  compression  required.  Some  technologies  are  “lossy”  because  the  decompressed 
images  are  reduced  in  size.  Lossless  methods  also  exist  where  data  file  size  is  reduced 
during  compression  but  none  of  the  data  is  lost  when  the  file  is  decompressed. 

G.  VIRTUAL  REALITY  MODELING  LANGUAGE 

VRML  is  a  draft  specification  for  adding  3D  data  to  the  Internet  via  the  WWW.  The 
current  vision  is  to  allow  for  a  3D  browser  to  search,  travel  and  interact  with  major 
repositories  of  information  on  the  WWW.  This  proposal  would  allow  Virtual  Reality  (VR) 
environments  to  be  incorporated  into  the  World  Wide  Web,  thereby  allowing  users  to"walk" 
around  and  visualize  actual  environments.  VRML  is  a  logical  markup  language  that  will  be 
used  for  non-proprietary  platform  independent  VR.  It  is  believed  VR  will  become  an 
increasingly  important  medium  and  will  be  accessible  due  to  increases  in  bandwidth  and 
high  end  computing  assets  availability.  This  mechanism  would  allow  users  to  share  VR 
models  and  possibly  interactive  simulations  on  a  global  basis  firom  desk  top  computers. 
Presently,  VRML  technology  allows  a  user  to  build  a  world  with  hyper  text  links  embedded 
to  allow  a  user  to  connect  to  another  world  or  another  information  repository.  This  is  a  low 
end  system  which  allows  movement  through  cursor  keys.  This  technology  has  great  potential 
for  global  interactive  3D  environments. 
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APPENDIX  B.  SADT/IDEFOMODELOFADDSS 


A.  PREFACE 

A  Structured  Analysis  and  Design  Technique  (SADT)^  commonly  called  IDEF  0  was 
used  to  model  the  activities  and  the  interrelations  of  these  activities  required  to  distribute 
decision  support  technologies.  This  model  is  nothing  more  than  a  tool  to  help  the  author 
better  understand  and  describe  the  requirements  and  relationships  of  the  processes  of  the 
Distributed  Decision  Support  Server  (DDSN).  The  system  in  focus  for  the  model  is  the 
DDSS. 


An  IDEF  0  model  has  a  single  subject.  The  subject  of  this  model  is  “Provide 
Distributed  Decision  Support  Technologies.”  Obtaining  the  correct  subject  is  critical  in  the 
development  of  the  model.  It  must  focus  on  understanding  the  system.  The  boimdaries  of 
the  system,  what  is  inside  and  what  is  outside  the  system,  must  be  clearly  defined.  The 
subject  must  be  bounded  to  concentrate  attention  on  the  system  being  described  and  avoid 
the  introduction  of  external  environmental  entities. 

An  IDEF  0  model  has  one  viewpoint  or  perspective.  The  viewpoint  of  this  model  is 
that  of  the  system  administrator  of  the  DDSN.  A  viewpoint  can  be  a  person,  place,  or  thing 
of  the  system  in  which  if  replaced,  could  watch  the  overall  operation  of  the  system.  Different 
views  will  yield  different  descriptions  of  the  system  being  modeled. 

The  IDEF  0  software  BPWIN®  was  used  to  develop  the  top-down  diagrams.  The 
diagrams  start  with  a  general  diagram  and  are  decomposed  into  more  specific  diagrams 
which  outline  tihe  activities  of  a  specific  system.  The  collections  of  these  diagrams  and  the 
natural  language  obtained  from  user  descriptions  compose  the  IDEF  0  model.  The  diagrams 
use  boxes,  which  represent  fimctions  or  activities  and  arrows  which  represent 
interconnections  between  the  boxes.  The  boxes  are  numbered  alphanumerically  and 
represent  the  origin  and  the  path  used  in  the  development  of  the  model.  A-0  is  the  top  level 
diagram  commonly  called  the  context  diagram.  AO  is  the  decomposition  of  the  context 
diagram.  This  diagram  will  contain  3-6  boxes  which  will  be  labeled  with  a  single  numeral 
(1, 2, 3).  When  these  boxes  are  decomposed,  they  will  become  the  Al,  A2,  A3  diagrams. 
This  process  continues  through  the  last  level  of  the  model.  The  arrows  identify  information 
or  data  needed  to  carry  out  the  fimctions  or  activities.  An  arrow  coming  into  a  box  from  the 


^The  explanation  of  the  SADT/IDEF  0  business  processing  and  enterprise  modeling  is 
summarized  from  Marcia,  David  A.,  and  McGowen,  Clement  L.,  IDEF  0/SADT Business 
Process  and  Enterprise  Modeling,  Electic  Solutions  Corp,  San  Diego,  1993. 

^BPWIN  1.50b  is  a  beta  version  produced  by  Logic  Works. 
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left,  is  input  data,  while  an  arrow  coming  out  of  a  box  on  the  right  side  is  output  data.  An 
arrow  coming  from  the  top  shows  a  control  order  while  an  arrow  coming  in  from  the  bottom 
shows  a  physical  resource  or  mechanism  required  to  do  a  function. 

Identifying  inputs,  outputs,  controls,  mechanisms  and  a  brief  description  of  the  functioning 
will  explain  each  box  of  the  model  of  that  activity.  The  purpose  of  explaining  each  box  is 
to  describe  how  each  activity  functions  independently  and  the  interaction  required  with  other 
activities  of  the  system. 

B.  NODE  A-0:  CONTEXT  DIAGRAM  OF  PROVIDE  DISTRIBUTED 
DECISION  SUPPORT  TECHNOLOGIES  (Figure  B-1) 


Activity  Number: 
Activity  Name: 

Input  Name: 

Output  Name: 

Control  Name: 
Mechanism  Name: 


A-0 

PROVIDE  DISTRIBUTED  DECISION  SUPPORT 
TECHNOLOGIES 

Consumers  Info,  Decision  Technology  Info,  Metadata 
Requirements,  Providers  Info 

Billing,  Distributed  Decision  Technology,  Management 
Reports,  Registration  Information,  Registration  Verification 
Legal,  Protocols,  Validation&Verification  Criteria 
Information  System,  Personnel 


Activity  Definition:  The  Distributed  Decision  Support  Network  (DDSS)  is  the 
main  focus  of  the  system.  The  DDSS  is  a  conglomerate  of  servers  which  interact  to  provide 
ftinctionalities  required  to  distribute  decision  technologies.  The  main  server  is  a  Hyper  Text 
Transfer  Protocol  (HTTP)  server  which  is  called  the  Distributed  Decision  Support  Server 
(DDSS).  The  DDSS  will  interact  with  other  types  of  servers  (SMTP,  FTP,  DBMS)  to 
provide  for  registration,  validation  and  interface  of  decision  technologies  to  all  users  of  the 
network.  The  protocols  control  the  interface  and  functioning  of  these  servers  of  the 
information  system. 


The  providers,  consumers,  and  the  technologies  interfaced  to  the  DDSN  are 
considered  external  entities  of  the  system.  The  system  requires  a  variety  of  information  from 
these  entities  to  provide  for  the  user/system  interface  and  the  actual  access  and  execution  of 
decision  technologies.  This  information  is  controlled  by  the  metadata  requirements 
established  by  the  DDSN,  legal  obligations  to  protect  private  information  established  by  the 
U.S.  government,  and  Validation  and  Verification  criteria  established  by  the  decision 
sciences  to  ensure  the  technology  provides  the  support  advertised. 


The  main  output  of  this  system  is  an  interface  to  a  “Distributed  Decision  Tech¬ 
nology.”  The  technology  is  physically  outside  of  the  system  but  the  interface  which  allows 
for  the  technology  to  be  accessed  and  executed  is  considered  an  output  of  the  system.  Other 
outputs  are  tools  that  are  required  for  the  management  of  the  system.  These  include  a  variety 


64 


of  reports,  registration  information,  and  billing  or  usage  information.  Registration  verifi¬ 
cations  are  sent  to  users  of  the  system  upon  successful  registration  as  a  provider  of  a  decision 
technology  or  a  consumer  of  the  system.  At  this  time,  the  distribution  of  decision 
technologies  is  a  semi-automated  information  system  which  requires  personnel  to  accomplish 
validation  and  management  activities.  Some  of  these  functions  will  be  automated,  however 
this  model  identifies  the  personnel  required  at  this  point  in  time. 

C.  ARROW  DEFINITIONS 

1.  Inputs 

Things  such  as  data  or  information  which  is  used  or  transformed  by  the  activity. 
Arrows  come  into  the  activity  from  the  right. 

a.  Providers  Info 

Information  about  the  provider  which  is  needed  to  register  the  provider  with 

the  DDSS. 


b.  Consumers  Info 

Information  about  the  consumer  which  is  required  to  register  the  consumer 
as  a  user  of  decision  technologies. 

c.  Decision  Technology  Info 

Information  about  the  decision  technology  which  is  to  be  registered  with  the 
DDSS.  Information  will  include  the  metadata,  validation  and  verification  criteria  unique  to 
the  application,  and  all  interface  requirements. 

d.  User  Request 

Upon  registration  users  (providers  and  consumers)  will  desire  different 
services  from  the  DDSS.  These  services  will  require  the  user  to  initiate  a  process  or  activity. 

2.  Outputs 

Represent  the  things  for  which  the  activity  has  transformed  or  created.  Arrows  leave 
the  activity  from  the  right. 
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a.  Management  Reports 

Reports  used  by  the  DDSS  staff  to  identify  users  of  the  system  and 
technologies  available  on  the  DDSS. 

b.  Registration  Information 

This  is  the  users  information  which  has  been  validated  and  is  available  within 
the  DDSS  databases. 


c.  Registration  Verification 

Notification  to  the  user  that  the  user  registration  process  has  been  completed. 

d.  Distributed  Decision  Technology 

A  technology  that  has  been  successfully  registered,  validated,  and  interfaced 
for  use  by  registered  consumers  of  the  DDSN. 

e.  User  Statistics 

Any  and  all  information  about  the  use  of  the  DDSS. 

3.  Mechanisms 

Represent  the  physical  aspects  of  an  activity  or  how  activities  are  realized.  Arrows 
come  into  the  activity  from  the  bottom  of  the  activity. 

a.  Information  System 

A  series  of  servers  that  allow  for  the  registration  of  users,  storage  of 
information,  search  of  available  technologies,  and  execution  of  those  technologies  in  an  open 
environment. 


b.  Personnel 

The  DDSS  staff  required  to  facilitate  the  registration,  verification,  and 
interface  activities. 

4.  Control 

These  are  things  that  constrain  the  functioning  of  the  activities.  Arrows  come  into  the 
activity  from  the  top. 
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a.  Protocols 

Set  of  established  rules  between  the  environment  and  activities  and  between 
activities  which  allow  for  shareability  and  execution  of  task  between  the  activities. 

b.  Legal 

Legislation  which  identifies  the  rights  of  individuals  and  mandates 
responsibilities  by  those  providing  services. 

c.  Validation  and  Verification  Criteria 

Criteria  established  by  the  decision  sciences  in  the  classification  and 
functioning  of  decision  support  application. 

d.  Metadata  Requirements 

Information  required  to  interface  and  classify  a  decision  technology. 

D.  NODE  AO:  DECOMPOSITION  OF  CONTEXT  DIAGRAM  -  PROVIDE 
DISTRIBUTED  DECISION  SUPPORT  TECHNOLOGIES  (Figure  B-2) 

Activity  Number:  AO 

Activity  Name:  PROVIDE  DISTRIBUTED  DECISION  SUPPORT 

TECHNOLOGIES 

Input  Name:  Consumers  Info,  Decision  Technology  Info,  Metadata 

Requirements,  Providers  Info 

Output  Name:  Billing,  Distributed  Decision  Technology,  Management 

Reports,  Registration  Information,  Registration  Verification 
Control  Name:  Legal,  Protocols,  Vahdation& Verification  Criteria 

Mechanism  Name:  Information  System,  Personnel 

Sub-activities:  A1  -  REGISTER  USERS 

A2  -  VALIDATE  TECHNOLOGY 
A3  -  INTERFACE  TECHNOLOGY 

Activity  Definition:  Same  as  A-0 
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E. 


NODE  Al;  DECOMPOSITION  OF  REGISTER  USERS  (Figure  B-3  through 
B-6) 


Activity  Number: 
Activity  Name: 
Input  Name: 

Output  Name: 


Control  Name: 
Mechanism  Name: 
Sub-activities: 


Al 

REGISTER  USERS 

Consumers  Info,  Decision  Technology  Info,  Metadata 

Requirements,  Providers  Info 

Registered  Consumers  Info,  Registered  Providers  Info, 

Registered  Technologies  Info,  Registration  Verification,  Users 

Reports 

Legal,  Protocols 
Personnel 

Al  1  -  PRODUCE  FORMS  AND  SCRIPTS 

A12  -  UPDATE  DATABASE 

A13  -  PRODUCE  REGISTRATION  VERIFICATION 


Activity  Definition:  This  activity  requires  the  system  to  capture  user  data,  to 
include:  Consumer  registration  information,  provider  registration  information,  and 
technology  metadata.  The  initial  registration  of  users  and  providers  is  done  on-line  via 
HTML  forms.  The  information  is  then  captured  and  stored  in  the  DDSN  database  by  the  use 
of  a  scripting  language.  Updating  the  database  invokes  another  script  which  produces  a 
registration  verification.  This  verification  is  in  file  form  of  E-mail  and  is  automatically 
generated.  The  metadata  required  to  register  a  decision  technology  involves  the  capture  of 
a  variety  of  information.  The  system  allows  for  the  capture  of  this  information  in  the  same 
way  users  are  registered.  An  optional  off-line  registration  form  can  also  be  used  via  E-mail. 
This  information  will  be  captured  in  the  same  format  (HTML)  and  be  used  to  update  the 
database  as  if  it  were  captured  on-line. 


Activity  Number: 
Activity  Name: 
Input  Name: 
Output  Name: 
Control  Name: 
Mechanism  Name: 
Sub-activities: 


All  (Figure B-4) 

PRODUCE  FORMS/SCRIPTS 


Input  Forms,  Input  Scripts 

HTML  3.0,  SMTP,  Metadata  Requirements 

HTTP  Server,  Programmers 

Al  1 1  -  BUILD  FORMS/SCRIPTS 

Al  12  -  VALIDATE  FORMS/SCRIPTS 

Al  13  -  INTERFACE  FORMS/SCRIPTS  TO  NETWORK 


Activity  Definition:  This  activity  develops  the  forms  and  scripts  required  to  capture 
user  information.  The  metadata  requirements  are  used  to  control  what  is  to  be  captured  by 
the  forms.  The  programmers  develop  a  set  of  forms  to  capture  the  pertinent  information  and 
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a  series  of  scripts  to  update  databases  and  initiate  registration  verification.  The  forms  and 
scripts  are  built,  validated,  and  interfaced  to  the  network  during  this  activity. 


Activity  Number: 
Activity  Name: 
Input  Name: 
Output  Name: 
Control  Name: 
Mechanism  Name: 


Alll 

BUILD  FORMS/SCRIPTS 
Metadata  Requirements 
HTML  forms.  Scripts 
HTML  3.0,  SMTP 
HTTP  Server,  Programer 


Activity  Definition:  Programmers  build  forms  using  an  HTML  editor  or  word 
processor.  Scripts  are  built  using  Perl  scripting  language.  There  are  a  variety  of  scripting 
languages,  however  Perl  is  used  in  this  system. 


Activity  Number: 
Activity  Name: 
Input  Name: 
Output  Name: 
Control  Name: 
Mechanism  Name: 


A112 

VALIDATE  FORMS/SCRIPTS 

HTML  forms,  Scripts 

Validated  HTML  forms.  Validated  Scripts 

HTML  3.0,  SMTP 

HTTP  Server,  Programer 


Activity  Definition:  Forms  and  scripts  are  validated  to  ensure  that  they  capture  the 
desired  information,  update  DDSN  databases,  and  invoke  verification  process  as  described 
in  Al. 


Activity  Number: 
Activity  Name: 
Input  Name: 
Output  Name: 
Control  Name: 
Mechanism  Name: 


A113 

INTERFACE  FORMS/SCRIPTS  TO  NETWORK 
Validated  HTML  forms.  Validated  Scripts 
Input  Forms,  Input  Scripts 
HTML  3.0,  SMTP 
HTTP  Server,  Programer 


Activity  Definition:  The  validated  forms  and  scripts  are  then  installed  within  the 
DDSN.  The  interface  between  the  DDSS,  DBMS  and  SMTP  server  is  tested  and  the  forms 
and  scripts  comprise  the  registration  module  of  the  DDSN. 


Activity  Number: 
Activity  Name: 
Input  Name: 


Al  2  (Figure  B-5) 

UPDATE  DATABASE 

Consumers  Info,  Decision  Technology  Info,  Providers  Info, 
Verification  Flag 
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Output  Name: 


Registered  Consumers  Info,  Registered  Consumers  Rpt, 
Registered  Providers  Info,  Registered  Providers  Rpt, 
Registered  Technologies  Info,  Registered  Technologies  Rpt 
Control  Name:  DBMS,  Input  Forms,  Input  Scripts 

Sub-activities:  A12 1  -  ADD  NEW  INFORMATION 

A122  -  MODIFY  EXISTING  INFORMATION 
A123  -  DELETE  INFORMATION 

Activity  Definition:  This  activity  allows  for  the  addition  of  new  users  and 
technologies,  modification  of  user  and  technology  information  and  the  deletion  of  registered 
users  and  technologies  to  the  DDSN  database.  The  DBMS  provides  the  management  tools 
to  the  staff  of  the  DDSN  in  the  form  of  reports,  statistics  of  use,  and  all  information 
pertaining  to  users  and  technologies  registered  with  the  DDSN.  The  database  is  updated 
during  online  registration  through  the  use  of  HTML  forms  and  Perl  scripts.  The  database  is 
accessed  by  the  users  through  the  HTTP  server  allowing  for  a  heterogeneous  interface. 

Activity  Number:  A 1 2 1 

Activity  Name:  ADD  NEW  INFORMATION 

Input  Name:  Consumers  Info,  Decision  Technology  Info,  Providers  Info 

Output  Name:  Added,  New  Consumer  Rpt,  New  Prov  Rpt,  NewTech  Rpt 

Control  Name:  DBMS,  Input  Forms,  Input  Scripts,  Legal 

Mechanism  Name:  Database  Server,  HTTP  Server 

Activity  Definition:  This  activity  allows  for  all  registered  users  of  the  DDSN  to  add 
new  information  to  the  DDSN  database. 

Activity  Number:  A 122 

Activity  Name:  MODIFY  EXISTING  INFORMATION 

Input  Name:  Consumers  Info,  Decision  Technology  Info,  Providers  Info 

Output  Name:  Modified,  Registered  Consumers  Info,  Registered  Consumers 

Info 

Control  Name:  DBMS,  Input  Forms,  Input  Scripts 

Mechanism  Name:  Database  Server,  HTTP  Server 

Activity  Definition:  This  activity  allows  for  all  registered  users  of  the  DDSN  to 
modify  existing  information  about  themselves  or  a  technology  which  they  have  registered. 

Activity  Number:  A 123 

Activity  Name:  DELETE  INFORMATION 

Input  Name:  Consumers  Info,  Decision  Technology  Info,  Providers  Info 
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Output  Name: 

Control  Name: 
Mechanism  Name: 


Deleted,  Deleted  Consumer  Rpt,  Deleted  Prov  Rpt,  Deleted 
Tech  Rpt,  Registered  Technologies  Info 
DBMS,  Input  Forms,  Input  Scripts 
Database  Server,  HTTP  Server 


Activity  Definition:  This  activity  allows  for  all  registered  users  of  the  DDSN  to 
delete  themselves  as  registered  users  and  to  delete  information  which  they  have  provided 
about  a  registered  technology. 


Activity  Number: 
Activity  Name: 
Input  Name: 

Output  Name: 
Control  Name: 
Mechanism  Name: 
Sub-activities: 


A13  (Figure  B-6) 

PRODUCE  REGISTRATION  VERIFICATION 

Registered  Consumers  Info,  Registered  Providers  Info, 

Registered  Technologies  Info 

Consumer,  Provider,  Technology,  Verification  Flag 

Input  Scripts,  SMTP,  SMTP 

Email  Server,  HTTP  Server 

A131  -  PROCESS  CONSUMER  VERIFICATIONS 

AI32  -  PROCESS  PROVIDER  VERIFICATIONS 

A133  -  PROCESS  TECHNOLOGY  VERIFICATIONS 


Activity  Definition:  This  activity  provides  an  e-mail  message  to  the  user  upon 
completion  of  registration,  verification,  and  validation  of  the  user  and/or  the  technology. 
This  action  completes  the  initial  registration  process  for  users  of  the  system.  Users 
registering  themselves  as  a  consumer  or  provider  obtain  an  immediate  reply  if  they  have 
successfully  registered.  An  on-line  message  via  the  clients  WWW  browser  is  sent  if  the 
registration  was  unsuccessful.  The  registration  of  a  decision  technology  requires  an 
extensive  validation  and  validation  process.  The  provider  of  a  technology  will  be  sent  an 
interim  notice  that  the  information  about  the  decision  technology  has  been  received  and  that 
the  validation  and  verification  process  has  been  initiated.  Registration  of  a  decision 
technology  is  not  completed  until  the  technology  has  been  validated  by  A2  VALIDATE 
TECHNOLOGY. 


Activity  Number: 
Activity  Name: 
Input  Name: 
Output  Name: 
Control  Name: 
Mechanism  Name: 


A131 

PROCESS  CONSUMER  VERIFICATIONS 

Registered  Consumers  Info 

Consumer  Verification 

HTTP,  Input  Scripts 

HTTP  Server 


Activity  Definition:  This  activity  generates  an  email  message  to  the  user  that 
confirms  their  registration. 
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Activity  Number: 
Activity  Name: 
Input  Name: 
Output  Name: 
Control  Name: 
Mechanism  Name: 


A132 

PROCESS  PROVIDER  VERIFICATIONS 

Registered  Providers  Info 

Provider  Verification 

HTTP,  Input  Scripts 

HTTP  Server 


Activity  Definition:  This  activity  generates  an  E-mail  message  to  the  user  that 
confirms  their  registration  as  a  provider  of  a  decision  technology. 


Activity  Number: 
Activity  Name: 
Input  Name: 
Output  Name: 
Control  Name: 
Mechanism  Name: 


A133 

PROCESS  TECHNOLOGY  VERIFICATIONS 

Registered  Technologies  Info 

Technology  Verification 

HTTP,  Input  Scripts 

HTTP  Server 


Activity  Definition:  This  activity  generates  an  E-mail  message  to  the  user  that 
confirms  the  receipt  of  information  pertaining  to  the  technology  and  that  the  technology  is 
being  verified  and  the  interface  is  being  investigated. 


Activity  Number: 
Activity  Name: 
Input  Name: 

Output  Name: 
Control  Name: 
Mechanism  Name: 


A134 

MAIL  VERIFICATION 

Consumer  Verification,  Provider  Verification,  Technology 
Verification 

Consumer,  Provider,  Technology,  Verification  Flag 
SMTP 

Email  Server 


Activity  Definition: 

user. 


This  activity  delivers  the  appropriate  E-mail  message  to  the 


F.  NODE  A2:  DECOMPOSITION  OF  VALIDATE  TECHNOLOGY  (Figure  B-7) 


Activity  Number: 
Activity  Name: 
Input  Name: 
Output  Name: 
Control  Name: 
Mechanism  Name: 


A2 

VALIDATE  TECHNOLOGY 
Registered  Technologies  Info 

Validated  Technology,  Validation& Verification  Reports 
Legal,  Protocols,  Validation&Verification  Criteria 
Information  System,  Personnel 
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Sub-activities: 

A21  -  CLASSIFY  DECISION  TECHNOLOGY 

A22  -  RUN  APPLICATION 

A23  -  VERIFY  APPLICATION  OUTPUTS 

A24  -  PRODUCE  V&V  REPORTS 

Activity  Definition:  This  activity  is  a  semi  automated  procedure  to  ensure  the 
correctness  and  accredited  the  decision  technology  for  use.  Intelligent  agents  and  human 
specialist  will  verify  the  model  description  and  classify  accordingly.  The  application  will 
be  run  against  parameters  given  by  the  provider.  Upon  verification,  validation,  and 
accreditation,  reports  are  archived  and  the  technology  is  ready  to  be  interfaced  to  the  DDSN. 

Activity  Number: 
Activity  Name: 

Input  Name: 

Ou^ut  Name: 
Control  Name: 
Mechanism  Name: 

A21 

CLASSIFY  DECISION  TECHNOLOGY 

Registered  Technologies  Info 

Classified  Technology  Info 

Legal 

Decision  Support  Specialist 

Activity  Definition:  Activity  categorizes  the  application.  The  registered  tech¬ 
nologies  info  is  used  to  identify  the  type  of  application  and  the  functional  area  that  it  can  be 
used  in.  The  application  is  given  an  appropriate  classification  which  will  be  used  for 
indexing  and  cross  referencing. 

Activity  Number: 
Activity  Name: 

Input  Name: 

Output  Name: 
Control  Name: 
Mechanism  Name: 

A22 

RUN  APPLICATION 

Classified  Technology  Info 

Application  Outputs 

Protocols,  Validation&Verification  Criteria 

Decision  Support  Specialist,  Information  System 

Activity  Definition: 

The  application  is  run  remotely  to  validate  operation 

Activity  Number: 
Activity  Name: 

Input  Name: 

Output  Name: 
Control  Name: 
Mechanism  Name: 

A23 

VERIFY  APPLICATION  OUTPUTS 

Application  Outputs 

Report  Data,  Validated  Technology 

Protocols,  Validation&Verification  Criteria 

Decision  Support  Specialist,  Information  System 

Activity  Definition:  Output  of  the  application  is  compared  with  the  expected  given 

at  registration  to  ensure  correctness 
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Activity  Number: 
Activity  Name: 
Input  Name: 
Output  Name: 
Control  Name: 
Mechanism  Name: 


A24 

PRODUCE  V&V  REPORTS 

Application  Outputs,  Classified  Technology  Info,  Report  Data 
Validation& Verification  Reports 
Validation& Verification  Criteria 
Decision  Support  Specialist 


Activity  Definition:  Reports  are  generated  for  validation,  verification,  and  accredit¬ 

ation  process  for  each  application  registered  and  accepted  for  use. 


G.  NODE  A3:  DECOMPOSITION  OF  INTERFACE  TECHNOLOGY 

(Figure  B-8) 


Activity  Number: 
Activity  Name: 
Input  Name: 
Output  Name: 
Control  Name: 
Mechanism  Name: 
Sub-activities: 


A3 

INTERFACE  TECHNOLOGY 

Registered  Technologies  Info,  Transaction  Request 

System  Statistics, ,  Distributed  Decision  Technology 

Legal,  Protocols,  Validated  Technology 

Information  System,  Personnel 

A31  -  IDENTIFY  INTERFACE  REQUIREMENTS 

A32  -  BUILD  INTERFACE 

A33  -  DISTRIBUTE  DECISION  TECHNOLOGY 

A34  -  MONITOR  USE  OF  TECHNOLOGY 


•  Activity  Definition:  Allows  users  to  access  registered  decision  technologies  by 
providing  a  common  interface  to  die  provider  of  the  decision  technology.  The  interface  will 
be  dependent  on  the  type  of  technology  and  the  type  of  servers  computer  assets  available  at 
the  providers  site.  The  registered  technologies  info  identifies  all  inputs  required  and  outputs 
of  the  technology.  If  the  provider  is  classified  an  independent  technology,  the  interface  is 
nothing  more  than  an  HTML  form  which  will  reside  within  the  DDSS  file  directory 
structure.  If  the  technology  is  exclusive  a  series  of  scripts  and  HTML  forms  will  interface 
the  application  with  the  HTTP  server  at  the  DDSS.  The  provider  must  provide  a 
combination  of  servers  to  allow  for  data  transfer  from  the  consumer,  output  back  to  the 
consumer,  and  a  DNS  to  allow  activation  of  application  possibly  through  a  transparent  Telnet 
session.  This  interface  allows  for  transparent  connection,  data  transfer,  and  execution  of 
technology.  A  feed  back  activity  is  also  required  to  monitor  the  use  of  any  given  technology. 
This  is  required  for  billing  of  both  consumer  and  providers  and  to  track  resource 
requirements. 


Activity  Number: 
Activity  Name: 
Input  Name: 
Output  Name: 


A31 

IDENTIFY  INTERFACE  REQUIREMENTS 
Registered  Technologies  Info 
Type  of  Interface 
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Control  Name;  Legal,  Protocols,  Validated  Technology 
Mechanism  Name:  Decision  Support  Specialist,  Programer 

Activity  Definition:  This  activity  identifies  the  type  of  technology  that  has  been 
registered  and  verifies  die  correctness  of  data  given  at  registration.  If  data  is  incomplete,  the 
POC  is  contacted  and  the  information  is  solicited.  After  all  information  is  available ,  the  data 
is  sent  to  the  Build  Interface  activity  for  automatic  setup  of  the  application  to  the  DDSN. 


Activity  Number: 
Activity  Name: 
Input  Name; 
Output  Name: 
Control  Name: 
Mechanism  Name: 


A32 

BUILD  INTERFACE 

Registered  Technologies  Info 

Specific  Technology  Interface 

Protocols,  Type  of  Interface,  Validated  Technology 

Decision  Support  Specialist,  HTTP  Server,  Programer 


Activity  Definition;  Presently  a  manual  process,  but  automation  is  envisioned.  A 
series  of  CGI  scripts  and  HTML  documents  make  up  the  interface.  An  exclusive  technology 
will  have  the  files  sent  to  the  providers  server.  An  HTML  file  summarizing  the  input  data 
will  also  be  maintained  at  the  DDSS.  This  file  is  the  application  entry  file  for  consumers  of 
the  network.  The  final  product  of  the  build  interface  activity  is  a  distributed  decision 
technology. 


Activity  Number: 
Activity  Name: 
Input  Name: 

Output  Name: 
Control  Name: 
Mechanism  Name: 


A33 

DISTRIBUTE  DECISION  TECHNOLOGY 

Registered  Consumers  Info,  Registered  Providers  Info, 

Registered  Technologies  Info,  Transaction  Request 

Distributed  Decision  Technology 

Protocols,  Technology  Interface 

Decision  Support  Specialist,  HTTP  Server,  Programer 


Activity  Definition:  This  a  control  activity  which  allows  registered  users  to  use 
registered  decision  technologies.  The  login  of  users  is  also  done  at  this  activity.  A  good 
analogy  here  is  a  menu.  The  user  is  provided  a  list  of  options  (register,  login,  use  a 
technology),  through  a  transaction  request  the  appropriate  activity  within  this  activity  is 
initiated. 


Activity  Number: 
Activity  Name: 
Input  Name: 
Output  Name: 
Control  Name: 
Mechanism  Name: 


A34 

MONITOR  USE  OF  DECISION  TECHNOLOGY 

Distributed  Decision  Technology 

Billing 

Protocols 

HTTP  Server,  Programer 
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Activity 
output  is  system 


Definition:  This  activity  tracks  the  usage  of  all  users  of  the  system.  The 
statistics  which  is  sent  to  other  processes  such  as  billing  and  resource  usage. 
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Figure  B-1.  DDSS  Context  Diagram  (Node  A-0) 


Figure  B-2.  Decomposition  of  Context  Diagram  (Node  AO) 
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Figure  B-3.  Register  Users  (Node  A-1) 


Figure  B-4.  Produce  Forms/Scripts  (Node  All) 
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Figure  B-5.  Update  Database  Node  (A12) 


NODE: 

A13 

TITLE:  produce  registration  verification 

NUMBER: 

_ ^ _ 

Figure  B-6.  Produce  Registration  Verification  (Node  A13) 
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Figure  B-7.  Validate  Technology  (Node  A2) 
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REQUIREMENTS 
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Figure  B-8.  Interface  Technology  (Node  A3) 
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